Chapitre 15 : 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 JavaScript.

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 des émissions totales de l'aéroport de Liège et la comparer à des émissions connues pour l'utilisateur (par exemple les émissions CO2 de la Wallonie, d'un petit pays, ...). Faites attentions aux échelles de temps.
Un graph affichant les émissions CO2 par modèle d’avion mis en comparaison au nombre de vols.
Afficher les émissions carbones totales pour une durée choisie (dynamiquement sélectionnable en fonction des données de la base de donnée). 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 l'aéroport est à (par exemple) 30% du total des émissions de la Chine, 20% avec les Etats-Unis, 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
Le design est réfléchi, le site est navigable, élégant, épuré
Le site est résistant à l'utilisateur : il n'y a pas de crash, d'injections SQL, ... Présenter un site avec une faille de sécurité mènera à un malus conséquent.
La visualisation est pertinente pour les fonctionnalités obligatoires et pour la fonctionnalité au choix.
Les nouvelles fonctionnalités sont complètes et fonctionnelles.

SQL :

Les requêtes SQL sont correctes.
Les requêtes SQL sont élégantes, directes et efficaces. Elles ne retournent pas de données qui ne seront pas utilisées par le contrôleur.

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 structuré. La nomenclature et l'organisation des modules et répertoires présentés dans l'énoncé sont respectées.
Les templates HTML sont propres. Les données paramétrables sont passées par l'application, et pas codées en dure.

Testing: - Le code est vérifié par des tests (point important). - Le coverage est bon, les parties non couvertes sont justifiables

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.
Le git ne contient pas de fichiers binaires, le VENV ou autres fichiers inutiles.

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

Une revue par les pairs (peer review) sera faite par sous groupe de 2 ou 3. Si votre groupe comporte 3 membres, alors il y aura un groupe de 3. 4 membres, deux groupes de 2. 5 membres, un groupe de 3 et un groupe de 2, et 6 membres, trois groupes de 2.

Un rendu préliminaire du projet (code uniquement) est à rendre pour peer-review en S11.

Vous ferez ensuite une revue par les pairs du travail rendu par un autre sous-groupe.

Cette review sera à faire dans les 3 jours. Comment faire une bonne review a été discuté en phase 2 : Comment faire une bonne review.

Ceci sera géré sur Moodle par un module spécifique qui vous guidera dans le processus de peer-review.

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)