Gestion évoluée des notes

Master-1 2005-2006

Version du jeudi 12 janvier 2006

Motivation

La mise en place du LMD a augmenté considérablement la complexité de la gestion des notes. Tout crédit obtenu par un étudiant dans une matière est conservé à vie. La validation d'une unité d'enseignement ne donne pas le même nombre de crédits selon le parcours envisagé par l'étudiant. Le nombre important des parcours rend difficile la tâche des jurys. De plus, en cette période de transition, les jurys doivent convertir les notes obtenues avant le LMD en crédits, en tenant compte du changement des matières enseignées, etc.

Au niveau de l'Université, il existe un logiciel général de gestion des notes, appelé Apogee. L'accès à ce logiciel est strictement contrôlé, une ou deux personnes ayant accès au niveau de l'UFR. De plus, uniquement les notes finales (données par le jury final) peuvent être entrées. Il n'est donc pas possible de distribuer la tâche d'attribution des notes aux enseignants responsables de chaque matière ou aux jurys. De même, aucun historique de modification d'une note (par correction d'une erreur ou par le jury) n'est disponible. Obtenir la situation de ses notes ou un relevé de notes nécessite un travail supplémentaire de la part des secrétaires.

Objectifs généraux

Le but de ce projet est de mettre en place un gestionnaire évolué des notes qui sera utilisé au niveau de l'UFR, voir même au niveau de l'Université. Il doit combler les manques soulignés ci-dessus et offrir une interface d'accès facile et sécurisée à tous ses utilisateurs (étudiants, enseignants, jurys, administration, secrétariat, etc.). Afin de faciliter sa mise en place et son administration, l'outil doit offrir des interfaces d'administration et des importations et exportations vers des fichiers. Comme nous sommes en pleine période de transition, l'outil doit être le plus dynamique possible, afin de suivre les changements à moindre coût.

Présentation détaillée

Note importante : Cette description peut évoluer en fonction des besoins ressentis durant le projet. Toute modification toit être documentée soigneusement dans le rapport du projet.

Définition des utilisateurs : Le gestionnaire interagit avec plusieurs classes utilisateurs, chaque classe ayant ses droits spécifiques. Chaque utilisateur doit être identifié par un système de nom d'utilisateur et mot de passe.

L'outil doit savoir gérer ces classes, leurs interfaces spécifiques et leur évolution.

Définition des informations relatives aux notes  : Les notes sont le cœur de la base de données. Une note est associée à une matière et un étudiant. Son équivalent en ECUE est calculé en fonction de l'inscription pédagogique de l'étudiant (son parcours), donc il peut évoluer en temps. Comme la valeur de la note peut changer tant que la note n'est pas validée, il faut pouvoir identifier l'auteur, la date et le motif du changement. Le changement d'une note qui n'est pas fait par le responsable de la filière donne lieu à une alarme d'information du responsable. Toute instance d'une note est conservée dans un historique.

Définition des inscriptions pédagogiques : Dans une année scolaire, un étudiant doit effectuer trois inscriptions pédagogiques : deux provisoires pour chaque semestre et une finale pour l'année. L'inscription finale est incluse dans l'union des inscriptions provisoires. Ces inscriptions pédagogiques sont importantes car elles fixent les matières pour lesquelles l'étudiant doit avoir une note (si l'étudiant passe un examen pour lequel il n'a pas fait d'inscription pédagogique, sa note est oubliée). Une inscription pédagogique est une liste de matières disponibles dans sa filière. Elle a un nombre de crédits attachés. Pour l'inscription finale uniquement, ce nombre doit être plus grand que celui qui est demandé pour la validation du parcours choisit. L'interface d'entrée de l'inscription pédagogique doit aider l'étudiant à réaliser une inscription pour un parcours choisit. Après avoir construit son inscription, l'étudiant doit demander la validation de cette inscription par le responsable de filière. Cette demande de validation est gérée par l'outil afin que le responsable de filière puisse savoir quelles sont les inscriptions en attente de validation et les valider.

Pour des raisons pédagogiques, il est important de pouvoir gérer l'historique des inscriptions pédagogiques validées par un étudiant.

Mise en œuvre

Nous utiliserons une architecture 3-tiers pour le logiciel de gestion de notes. La première partie sera constituée de l'interface Web des utilisateurs. Le 2e tiers sera constitué des logiciels tournant sur un serveur qui aura la tâche d'interface avec la base de donnée. Le dernier tiers sera la base de données lui-même.

Pour l'écriture de l'interface Web, vous utiliserez XHTML et CSS. Pour l'interface avec la base de données, on vous propose deux langages : PHP (langage non-typé mais très utilisé) ou Ocaml (langage typé évolué, peu utilisé). Pour la base de données, vous utiliserez un SGBD disponible sur les serveurs de l'UFR.

Comme votre logiciel aura plusieurs versions (voir la section Organisation), il est recommandable d'utiliser un outil de gestion de versions comme RCS ou CVS.

L'utilisation de langages et outils de génie logiciel, par exemple UML, sera bien venue, même si cela ne concerne que la documentation du projet.

Le projet sera soigneusement documenté afin qu'il puisse être facilement modifié et utilisé.

Organisation

Ce projet aura lieu durant le deuxième semestre et sera validé en deux parties :

  1. Première période (6 semaines) : la définition du modèle de la base de données et son implémentation en utilisant des fichiers de script ; définition et implémentation des interfaces d'administration de la base de données. Pour la première période, le travail est à effectuer en groupe de 3 étudiants. à la fin de cette période, une soutenance aura lieu et donnera lieu à une fiche individuelle de recommandations pour la deuxième période. Nous choisirons deux ou trois implémentations (ou proposerons une autre implémentation) pour la base de données à utiliser en deuxième partie.
  2. Seconde période (6 semaines) : familiarisation et adaptation à la nouvelle base de donnée ; définition et implémentation des interfaces d'utilisation pour une base de données commune à tous plusieurs projets. La soutenance finale portera sur toute l'implémentation. La note finale sera la moyenne des deux soutenances. Pour la deuxième période, le travail sera à effectuer individuellement ; chaque étudiant prenant en charge au moins une interface avec une classe d'utilisateurs.

Les séances de TD en début de projet seront des minis cours sur les outils que vous n'êtes pas censés à connaître (XHTML, CSS, RCS, CVS, PHP ? et Ocaml). Puis, nous passerons à la définition du modèle de la base de données.

Calendrier :