Chapitre 13 : Projet phase 4, le grand final!¶
Ce chapitre présente la phase 4 du projet. Il se basera sur les phases précédentes.
L'objectif de cette phase est d'ajouter des graphes à votre site afin de visualiser les données présentes dans la base de données. Pour cela, vous allez utiliser la bibliothèque Chart.js. Cette bibliothèque JavaScripts open source permet de créer des graphiques et de les intégrer à un site web. La prise en main de Chart.js ne demande pas de base en JavaScripts
Des graphes pour une meilleur visualisation¶
Pour créer un graphique efficace qui permet de visualiser les données de manière claire et concise, il est important de prendre en compte plusieurs facteurs clés. Tout d'abord, il est essentiel de choisir le type de graphique le plus approprié en fonction des données que l'on souhaite visualiser.
Ensuite, il est important de bien choisir les axes du graphique et de s'assurer qu'ils sont nommés de manière claire et précise, en incluant les unités de mesure si nécessaire. Il est également important de s'assurer que le graphique est suffisamment grand pour que les données soient facilement lisibles.
Enfin, il est important d'utiliser des couleurs claires et cohérentes pour les différentes parties du graphique, en utilisant des nuances différentes pour les différents groupes de données si nécessaire. Il est également important d'inclure une légende claire qui permet de comprendre facilement ce que chaque élément du graphique représente. En suivant ces principes de base, il est possible de créer des graphiques qui permettent de visualiser efficacement les données et de communiquer clairement les informations importantes.
Ces concepts ont été présentés en S8.
Objectif de la phase:¶
Durant cette phase vous devrez implémenter les fonctionnalités suivantes:
Un graphe cumulatif des émissions totales de chacun des 5 aéroports belges et la comparer à des émissions connues pour l'utilisateur (par exemple les émissions CO2 de la Wallonie, d'un petit pays, ...)
Pouvoir afficher les émissions carbones totales d'un aéroport pour une durée choisie et pour un aéroport choisi. Le graph permettra de comprendre quels sont les pays avec qui ces émissions sont partagées. Par exemple l'aéroport de Liège a beaucoup d'échange avec la chine. On devrait voir que pour la période donnée, le total des émissions de LGG est à (par exemple) 30% du a des vols avec la Chine, 10% avec Israël, etc...
Une fonctionnalité au choix : demander à votre assistant/tuteur référent si vous n'avez pas d'idées.
Votre code Python devra être clair, documenté et accompagné de tests unitaires.
Comme d'habitude, chaque groupe DOIT réaliser son travail en utilisant la Forge UCLouvain qui utilise la plateforme GitLab et le gestionnaire de version Git. Ceci permettra de garder une trace des contributions des différents membres du groupe.
Vous veillerez, bien entendu, à écrire du code Python clair, documenté et accompagné de tests unitaires. Une première version de votre projet devra être prête avant la fin de la S11. En S12, vous fournirez du feedback détaillé à d'autres groupes d'étudiants. Ensuite vous utiliserez le feedback reçu pour améliorer votre propre projet et présenterez votre prototype à l'équipe enseignante en S13.
Rapport¶
Sur Moodle, vous remettrez un rapport qui répond aux critères ci-dessous, et contiendra également des captures d'écrans de toutes les pages importantes du site, de façon à ce que si un problème sur la version Coolify du site se présente, nous puissions nous faire une idée du design du site. La soumission du rapport se fait au format ZIP, avec le rapport d'une part, et une copie du code du site d'autre part. Le code ne doit pas contenir de fichiers binaires ou le VENV, il devrait donc être équivalent au contenu taggué du Git.
Critères d'évaluation¶
Rapport:
Le rapport est clair, complet mais concis.
Le rapport contient des captures d'écrans de toutes les pages importantes du site et les présente brièvement
Le rapport présente les fonctionnalités implémentées, en particulier il détaillera l'implémentation des graphes et les choix pour la représentation des données.
Le rapport détaille aussi les nouveaux tests ajoutés pour la visualisation et la nouvelle fonctionnalité.
Site:
Le site fonctionne et est en ligne
L'intégration des nouvelles fonctionnalités est complète (x3)
Le design est soigné
L'interface est cohérente, le layout du site est compréhensible
Documentation du code:
Le code est commenté en utilsant des docstrings tels que présenté au cours.
Code:
Le code est correct.
Le code est vérifié par des tests (point important).
Le coverage est bon, les parties non couvertes sont justifiables
Le code est structuré. La nomenclature et l'organisation des modules et répertoires présentés dans l'énoncé sont respectées.
Git:
L'ensemble des modifications importantes a été fait en utilisant des merge request.
Les merge request ont fait l'objet de review systématiques.
Dates¶
Aucune dates n'est précisément donnée dans ce syllabus pour éviter les incohérences, notamment entre LLN et Charleroi. Moodle est toujours la source correcte pour les dates.
Peer review¶
Un rendu préliminaire du projet (code uniquement) est à remettre à deux autre groupes pour peer-review le dimanche de S11.
Vous ferez ensuite une revue par les pairs (peer review) du travail rendu par un autre groupe, comme lors de la phase 2.
Cette review sera à faire dans les 3 jours.
Rendu final¶
Le rendu final du rapport et de votre code est à faire en S12.
Vous n'aurez donc que 4 jours pour intégrer les commentaires faits par l'autre groupe lors de la peer-review. Cependant vous pourrez présenter des modifications proposées dans la peer review mais que vous n'auriez pas eu le temps de faire à la présentation.
Présentation et dynamo¶
En S13, vous devrez avoir remplis un nouveau module Dynamo sur Moodle, différent de celui de la phase 2 afin d'évaluer le travail de groupe.
Vous devrez présenter votre site web ainsi que ces fonctionnalités lors d'une présentation orale le jour de votre TP.
La présentation comportera une partie sur le projet, l'architecture du code, (avec des diapositives en support) de 5 minutes, une démonstration de 3 minutes et un Q&A de 2 minutes. Prévoyez une vidéo de secours pour la démonstration.
Les détails de cette présentation vous seront communiqués en temps voulu sur Moodle.