Skip to content

Latest commit

 

History

History
45 lines (38 loc) · 7.79 KB

Collaborative exams.adoc

File metadata and controls

45 lines (38 loc) · 7.79 KB

Collaborative exams

Mise au point collaborative de questionnaires

Contexte

Ce projet permettra à des enseignants de créer des ensembles de questions et réponses. Ces questions peuvent être réutilisées par d’autres enseignants et combinées pour créer des questionnaires ou des sondages. Les étudiants pourront se servir de ces ensembles de questions pour s’entrainer.

L’application laissera la place à la subjectivité des enseignants, en leur permettant par exemple de privilégier certaines questions. Pour permettre la réutilisation, l’application séparera clairement les informations objectives (par exemple la bonne réponse à une question) des informations subjectives (dépendant des enseignants, par exemple l’évaluation de la difficulté, le choix des réponses…).

(On pourra éventuellement s’inspirer de deux implémentations existantes.)

À faire

  • Interfaces et objets pour Question et objets associés. Une question comprend un énoncé (« phrasing »), une langue, un ensemble de réponses possibles, chacune associée à l’information indiquant si cette réponse est correcte, et un auteur. Un auteur est identifié par un e-mail. Utiliser un objet Person pour les auteurs. Un énoncé et une réponse sont des textes simples. L’ensemble de réponses peut être remplacé par une information « Y/N » ou « T/F » ou « free », indiquant une question oui / non, ou vrai / faux, ou de réponse libre. Créer à cet effet une interface MultipleChoiceQuestion qui étend Question. L’auteur peut associer un identifiant personnel (string) à une question. Ceci est stocké hors de l’objet Question. Cet identifiant peut changer. (La paire (auteur, identifiant) doit être unique.) Ces objets sont immuables.

  • Lecture et écriture d’une question en format JSON.

  • Édition d’une nouvelle question Y/N à l’aide d’une interface graphique. La question est sauvegardée dans un fichier appelé Q1.json dans le répertoire courant, ou Q2.json si Q1.json existe, etc.

  • Quand on arrive au bout des numéros à un chiffre, renommer tous les fichiers en ajoutant un zéro en préfixe du numéro (par exemple Q17.json devient Q017.json).

  • Interfaces graphiques pour éditer d’autres types de questions.

  • Création d’examens (autrement dit, de questionnaires) : un examen (Exam) regroupe un ensemble de questions, ordonnées ; il a un auteur ; il est immuable. Un MultipleChoiceExam contient uniquement des questions de type MultipleChoiceQuestion. Une interface graphique permet à un utilisateur de sélectionner un sous-ensemble de questions pour intégrer un examen.

  • Pouvoir passer un examen, et obtenir sa note après l’examen (dans le cas d’un MCE). Les réponses sont également enregistrées dans le répertoire courant pour pouvoir être visualisées par la suite ; ces réponses ont un auteur et identifient l’examen auquel elles répondent.

  • Il ne doit pas être possible de modifier un examen après que des réponses aient été fournies. Éditer une question d’un examen ou un examen qui a une réponse crée un nouvel objet plutôt que modifier l’existant.

  • L’enseignant peut spécifier le coefficient associé à chaque question, voire, la note associée à chaque réponse (points négatifs, …)

  • Stocker une relation d’équivalence « same ability » entre questions, associée à une personne. Une personne peut indiquer qu’une question interroge, à son avis, sur la même compétence qu’une autre. (On pourra l’utiliser pour éviter que ces questions figurent dans le même examen.)

  • Stocker une relation « improvement » entre questions, associée à une personne. Une personne peut indiquer qu’une question, à son avis, est meilleure qu’une autre, tout en interrogeant sur les mêmes compétences. Exemples : correction d’une faute d’orthographe ; correction d’une réponse erronée. (On pourra l’utiliser pour présenter uniquement les questions avec les meilleures formulations.) Ceci implique Same ability et At least as subtle as.

  • Serveur web qui renvoie une question en JSON au hasard étant donné une paire (e-mail auteur, identifiant personnel d’une question).

Autres idées

  • Création et visualisation de questions au format asciidoc. Il faudra pouvoir voir le rendu en plus du code source.

  • Stocker une relation « at least as subtle as » entre questions, associée à une personne, et créer un servlet associé. Une personne peut indiquer qu’une question est (à son avis) au moins aussi subtile qu’une autre. Une question est au moins aussi subtile que sa variante ssi la connaissance de la réponse à la première question implique nécessairement la connaissance de la réponse à la deuxième. Exemples de variantes aussi subtiles : une reformulation dans un autre style littéraire, ou une traduction. La relation est réflexive mais pas nécessairement symétrique ni complète.

  • Chaque personne peut associer un identifiant personnel à chaque question (y compris celles dont la personne n’est pas auteur). La paire (personne, identifiant) doit être unique. Chaque personne peut associer un ensemble de sujets à chaque question (exemple : Math, Java, Programmation). Ces sujets sont personnels. (Donc deux personnes peuvent indiquer des sujets différents pour une même question.)

  • On peut afficher ce que pensent tous les utilisateurs de la relation entre deux questions.

  • Récupérer toutes les questions qui portent le sujet S donné par l’utilisateur U. Plus généralement, toutes les questions qui satisfont une certaine requête.

  • Un utilisateur peut déclarer qu’il trouve que les questions marquées par untel comme étant de tel sujet sont de tel sujet (éventuellement différent), à son avis. Il peut cependant soustraire certaines questions de cet ensemble. (Exemple : le sujet « Java » regroupe, à mon avis, toutes les questions marquées « programmation » par Untel sauf les questions q1 et q2.) Cet ensemble s’ajuste lorsque l’utilisateur suivi modifie son opinion.

  • Un utilisateur peut créer un modèle de questionnaire : il indique combien de questions doivent être tirées de quels sujet, avec éventuellement une probabilité de tirage pour chaque question au sein d’un sujet donné pour ce questionnaire.

  • Un utilisateur peut utiliser un modèle de questionnaire pour générer un ou plusieurs questionnaires.

  • Un utilisateur peut modifier un questionnaire (créé manuellement ou généré).

  • Affichage d’un questionnaire (généré sur le champ ou précédemment) et recueil des réponses de l’étudiant.

  • Affichage de la note de l’étudiant à l’issue du questionnaire.

  • Affichage d’une correction à l’issue du questionnaire.

  • Un utilisateur peut indiquer à quels autres utilisateurs il fait confiance. Cela a un impact uniquement sur les relations. Un utilisateur se fait toujours confiance.

  • Calcul de relations résultantes : l’affichage indique à l’utilisateur, et prend en compte les relations qui sont soit plébiscitées par au moins 80% des utilisateurs, soit indiquées par des utilisateurs auxquels il fait confiance et contredites par moins de 20% des utilisateurs.

  • Export d’un questionnaire en PDF.

  • Possibilité de créer des questions et des questionnaires en local plutôt que en ligne (via client lourd). Pour éviter que les étudiants voient les questions avant l’examen.

  • Possibilité d’envoyer en ligne des questions et questionnaires créés localement.

  • Un utilisateur peut indiquer une relation de préférence subjective entre deux questions. Dans ce cas il ne prétend pas que l’une est objectivement meilleure que l’autre, mais il souhaite néanmoins que la moins bonne ne soit jamais prise dans un questionnaire.