Évaluation

La note sera établie sur la base de trois évaluations portant sur :

Une évaluation écrite individuelle (S. Rumley).
Une note de projet:
1. Un entretien individuel où seront sondées les contributions de chaque étudiant et sa maîtrise générale du projet.
2. Une note de groupe pour le projet réalisé (avec le droit de donner des bonus/malus individuels voir une note différente par individu selon les critères communiqués par le prof responsable g chaque aspect du projet).

Vous recevrez les critères d’évalution de chaque aspect du projet par le prof. responsable. Ceci dit: La note attribuée au projet de groupe tiendra essentiellement compte des critères suivants:

L’organisation du groupe: distribution équitable du travail, travail régulier le long du semestre, tenue des réunions, planification et conduite du projet, traces écrites (tenue du journal conduite, PV de séances, messages de commit propres). Le respect des échéances des différentes étapes du projet (selon les consignes de chaque prof.).
L’utilisation du Gitlab board pour la planification des tâches (tâches bien définies, estimées, tenue du board à jour: backlog, tâches en cours de réaliser, réalisés, …)
La qualité de l’analyse de l’application existante.
la qualité, couverture (en termes de thèmes abordés), et motivation des idées d’amélioration proposées.
La qualité de la conception et la réalisation des idées validées.
L’évaluation du code source soumis (et le fonctionnement des différents modules et conformité aux attentes).
Au niveau des tests:
- la qualité de la démarche de test. Plus précisément: la satisfaction de tous les tests requis (unitaires, intégration, UI automatisés, end-to-end, et tests manuels), la pertience des tests choisis, leur validation avec la prof, documentation, et réalisation.
- explication des différents tests dans le README, les tests passent, facilité de lancer les outils, de tester, couverture des tests (oü trouver l’info).
La qualité de la rédaction et du rapport final (obligatoirement en Latex) : ce rapport ne doit notamment pas être rédigé dans un ordre chronologique de réalisation (ce n’est pas un journal de bord !) mais structuré en fonction des différentes parties du projet.
La gestion de l’évolution du code source (bon usage de Git):
- état du pipeline, forme du graph, message des commits, nombre de commits, processus de merge (merge request, comments, approval, qui merge), origine des fichiers (favoriser le git move).
- Etat du repo (brain main) au rendu: pipeline, qualité du README, organisation du code, aspects de sécurité, messages d’erreur/warning lors de l’utilisation.