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.

Rapport

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 en ligne du site se présente, nous puissions nous faire une idée du design du site.

Le rapport sera basé sur un format texte et directement fait sur Git, en Latex ou Markdown (.md), ou ReStructured text (.rst) mais ce dernier format est à éviter car il est plus difficile à écrire. Le format Latex doit être également rendu au format PDF sur git. Il est important que le rapport soit fait via Git, l'historique Git pourra être utilisé pour voir les modifications apportées au rapport.

Le dépôt Git ne doit pas contenir de fichiers binaires ou le VENV. Vous devez pousser la version finale de votre code sur la branche main de votre dépôt Git. Vous devez également créer un tag phase4 pour marquer la version finale de votre code.

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. La deadline est donnée sur Moodle. Vous devez rendre le code de votre projet, ainsi que le rapport via git (voir ci-dessus). Le code doit être taggé avec le tag "phase4".

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 d'environ 5 minutes. Prévoyez une vidéo de secours pour la démonstration.

Dans votre présentation vous devez présenter votre projet et l'architecture du code, montrer qu'il est bien organisé (MVC, etc). Vous devez présenter comme si vous vous adressiez à des informaticiens externes.

N'oubliez pas de :

  • Vous présenter

  • Expliquer l’objectif global du projet

  • Présenter les grandes fonctionnalités du site, et particulièrement votre fonctionnalité personnalisée

  • Avoir une conclusion

  • Avoir une présentation sans fautes et attractive

  • Avoir une bonne prestance et une bonne élocution

  • Tout le monde doit parler

  • Vérifier le timing de votre présentation (5 minutes) et de votre démo (3 minutes)