BoardZ Moodle Stat Project

Ce projet est porté par l'Université d'Avigon (UAPV) sous la direction de Thierry Spriet,Vice-président délégué au numérique et à l'innovation pédagogique, et a été confié à la société ActiveProLearn, en Décembre 2018. ActiveProLearn est un laboratoire privé d'innovation pédagogique et technologique dans l'éducation spécialisé sur socle LMS MOODLE.

Le projet BoardZ reprend les mêmes objectifs que son prédécesseur (AVP BoardZ sur Github), mais au sein d'un partenariat public/privé destiné à :

• Fournir un support au dispositif permettant à d'autres acteurs d'utiliser la technologie avec une garantie d'assistance.
• Garantir une viabilité à long terme de l'effort architectural et technologique.
• Assurer une construction adoptant des normes industrielles et des standards d'architecture propre à la nécessité du projet, dans une vision de construction à long terme.
• forger un modèle de soutien budgétaire à long terme, indépendamment des décisions ou changments d'environnement locaux.

Bénéficiant d'une longue expérience et d'une recherche opérationnelle de plusieurs années sur les thèmes des statistiques, calculs de temps, tracking, reporting, extraction de données à partir d'une plate-forme Moodle, le projet récupérera des éléments du projet BoardZ initial, mais en intégrant sa propre ligne de design technique.

Les objectifs de BoardZ deuxième génération, seront de :

• Anticiper les problèmes de performance sur des calculs à forte volumétrie de population et d'usages générés.
• Introduire des principes d'extensibilité, afin que le dispositif de calcul puisse être complété, amendé, étendu.
• S'appuyer sur des design simples, avec des technologies et des usages de formats connus par la communauté Moodle (tels que templates Mustache, bases de données MySQL/MariaDB)
• Adopter autant que possible des syntaxes et des sémantiques proches du lexique Moodle, afin de ne pas créer une rupture de culture.
• Récupérer des définitions fonctionnelles de la version antérieure lorsque c'est pertinent.
• Récupérer des concepts, algorithmes et éléments d'architecture de la version antérieure lorsqu'ils sont pertinents pour la nouvelle architecture.
• Récupérer des assets de la version antérieure lorsqu'ils sont facilement réutilisables.

Afin de pouvoir adresser des performances de calcul et d'absorption en temps réel sur des volumes de données importants ou sur des environnements multi-tenants (Moodle multiples, Moodle en batterie virtualisés (VMoodle)) les choix de départ de la version 2 sont différents de la première version développée en PHP sous Symphony.

L'objectif final est de disposer d'un serveur de calcul autonome capable de suivre en temps quasi réel l'ensemble des activités et usages de la population inscrite, afin d'en tirer des indicateurs pédagogiques et opérationnels sans altérer la performance frontale de Moodle.

L'objectif de calcul est important, en ce sens que les requêtes et agrégations de données peuvent adresser des formules non-linéaires (quadratiques, n-quadratiques) dans une exploration temporelle multi-dimensionnelle. de ce fait, les charges de calcul et l'organisation du stockage ne serait pas supportable s'il était directement intégré dans le code de Moodle et opéré comme service directe du LMS.

Accomplir cet objectif de pouvoir calculer efficacement un grand nombre d'indicateurs dans un grand nombre de contextes variés, et sur des formules non linéaires, nécessite de dissocier le moteur de calcul sur une infrastructure dédié, et de créer les ponts d'alimentation et de restitutions de données entre le serveur et l'environnement d'exploitation moodle.

Au delà de l'objectif architectural (et ce que l'objectif architectural doit servir), c'est le besoin, pour les institutions d'enseignement, de pouvoir disposer d'indicateurs réflexifs et comparés sur l'apprentissage, permettant à un apprenant (ou à un enseignant) d'observer son positionnement relatif par rapport au groupe, la promotion ou la session.

En effet, le numérique nous permet de collecter en continu des données élémentaires dont l'exploitation permet de donner des indications sur le “comportement d'usager” de l'utilisateur. Il serait déontologiquement abusif d'induire une extrapolation sociologique du “comportement d'usager” et de réaliser une projection sur le profil psychologique, social ou cognitif de l'utilisateur, mais à une échelle statistique, ou comparée, sur une population donnée, soumise au même “contrat institutionnel” qui définit les objectif et le cadre dans lequel ces objectifs sont proposés, des déductions des signaux que représentent les traces de comportement sur la plate-forme restent exploitables.

• Objectif 1 : sur la base d'activités sélectionnées et choisies, un positionnement comparatif des indicateurs de l'individu par rapport à un groupe de référence, appelé également indicateur de positionnement

Exemple :

Un forum est mis en place comme point central de l'animation d'un cours. La participation à ce forum a été institutionnellement établie comme une contrainte principale du contrat pédagogique. Tous les inscrits subissent la contrainte (pas d'auditeur libre ou d'exception de statut). Dans ce cas la mesure comparée du nombre d'intervention dans le forum est un des indicateurs possibles d'analyse du positionnement d'un étudiant dans son groupe de référence (mais pas le seul)

• Objectif 2 : Le calcul de temps de connexion, à des fins de comptabilité des actions de formation continue.

Deux défis majeurs sont identifiés dans ce projet :

1. Le défi de la performance et la réactivité des affichages statistiques
2. Le défi de la maniabilité et la flexibilité d'administration et de configuration
3. Le défi de l'évolutivité et l'extensibilité

Le défi de la performance vient essentiellement d'une volumétrie prévisible importante dans le cadre d'utilisation de plates-formes universitaires, avec des populations d'inscrits que quelques milliers à quelques dizaines de milliers d'étudiants.

Si on table sur une adoption croissante des indicateurs dynamiques dans l'usage des interfaces de cours, et d'un appel croissant à des “tableaux de bord” agrégés pour piloter la pédagogie, alors une croissance horizontale et verticale de la volumétrie doit être anticipée.

Le requétage temporel sur des grandeurs historisées pose également un problème d'efficience de calcul. Si les résultats sont calculés “au moment du rendu”, des stockages classiques des échantillons doivent être systématiquement reparcourus pour obtenir les valeurs d'indicateurs sur la période demandée. Précalculer ces résultats sous la forme d'un simple cache de requêtes n'est pas une solution, car un changement infime dans la période souhaitée entraine un nouveau stockage de résultat. La consommation en cache sera alors énorme.

Le défi consiste donc à trouver un modèle de données capable de proposer un compromis entre ces deux contraintes.

Par maniabilité, on entent tous les principes qui permettront d'ajuster et de paramétrer les résultats, ajouter des configurations supplémentaires par rapport à celles des objectifs de départ. Ceci suppose de créer une couche de définition complète des données et entités manipulables par BoardZ, afin de pouvoir monter des couches d'administration au dessus du moteur. Ces couches d'administration devront permettre d'administrer efficacement les différentes structures internes du serveur et ses services rendus.

On distinguera donc dans le serveur :

1. les objets de “structure”, qui constituent l'ossature fondamentale du projet. Ces objets ne seront pas administrés, mais configurables lorsque cela paraîtra nécessaire par des fichiers de configuration.

Exemple : un Scheduler d'extraction de log est un organe structurel technique qui aspire les logs d'une plate-forme moodle. Savoir sous quelle méthode d'extraction les logs seront récupérés relève de la configuration de structure.

1. les objets représentant des services ou des fonctionnalités statistiques 'l'objet applicatif du projet), qui devront par contre être administrables.

Exemple : un Parser de log qui capture une situation précise dans les logs pour la transformer en données d'indicateur rentre dans une fonctionnalité statistique objet de l'usage du BoardZ. Sa présence dans un Scheduler d'extraction de log doit être administrable.

BoardZ est un projet ambitieux, qui se donne un horizon de plusieurs années de développement, avec potentiellement des intervenants multiples. Il est donc nécessaire qu'une structure solide d'architecture en permette l'évolutivité à terme.

Les techniques qui permettent l'évolutivité et l'extensibilité des projets logiciels sont connues et répertoriées. On trouvera (non exhaustif) :

• L'architecture par plugins : En créant des points particuliers où des paquets de code peuvent être ajoutés au code initial et être reconnus et pris en charge comme des extensions. Cette méthode convient à la fois au projets de “script” ou aux projets structurés en programmation “Objet”.
• L'extension de classes : Principalement adaptée aux projet fortement orientés “Objet”, elles reposent sur des principe de “Fabrique” ou “Fabrique abstraite”, permettant à un projet de remplacer l'usage standard d'une classe par une classe plus riche définie et ajoutée ultérieurement au projet.
• L'abstraction et les méta-modèles de la persistance de données : Les méta-modèles et abstractions de modèles de données permettent de stocker dans relativement peu de définitions des constructions très différentes. Un modèle très abstrait réduit à un couple “entité - attribut” pourrait en théorie stocker les données n'importe quelle application, mais présente un problème important de performance, car l'accès à certaines données peut se révéler très indirect (et donc très long). L'abstraction doit donc être introduite de manière raisonnée pour permettre des stockages directs là où la performance est critique et des stockages plus “génériques” là où elle est moins indispensable.

Quels sont les points clefs de l'extensibilité ?

• L'auto-découverte ou auto-enregistrement : Il s'agit d'organiser comment l'applicatif peut intégrer des nouvelles portions de code par simple “ajout” de fichiers. L'applicatif doit être en mesure de soit :
  • directement utiliser le code ajouté et en proposer les principes dans ces interfaces
  • soit, si l'usage du code repose sur des registres et descripteurs, être capable d'aller mettre à jour automatiquement ces registres lorsque le code a été ajouté.
• La transparence des chaines de traitement : Il s'agit ici de faire en sorte que toutes les étapes et parties intermédiaires qui n'ont pas de rapport direct avec la fonctionnalité étendue soit le moins sensible possible au code de la fonctionnalité. Étendre l'application doit revenir, si l'architecture est bien construite, à ajouter juste les modifications qui concernent la fonctionnalité (les librairies, les réglages, les “templates”, les ressources propres), sans qu'aucune structure du “cœur” ne soit concernée par ces modification. En général, le transport de bout en bout de structures de données texte (sérialisées json ou non, suivant les couches à traversées) est une pratique efficace.
• Le découplage : Principe par lequel les transformations d'une partie n'impactent pas le tout mais seulement une fonction de transfert entre cette partie et le reste de l'applicatif.

• Journal de bord : Le journal de bord des développements en cours.
• Documentation de conception : Les principes de construction.
• Indicateurs, exemples d'analyse : L'analyse et la méthode de décomposition d'indicateurs.
• Documentation d'installation : L'installation du serveur et sa mise en oeuvre.
• Documentation d'administration : L'administration du serveur. (guide d'usage)
• Documentation d'exploitation : Les tâches programmées et le fonctionnement continu du moteur.
• Documentation d'intégration : L'intégration dans Moodle.
• Performances : Mesures de performance.
• Documentation d'extension : Les APIs et l'extensibilité.
• PhpDoc des classes

backend boardz site moodle cible (ma qualif)