SAE S2.02 : Consultation/modificaion d'une base de jeux vidéos
Le thème
Le projet utilise une base de données de jeux vidéos (créée par Jérôme Cutrona, IUT de Reims). Il consiste à écrire une application web qui permet :
- la consultation/recherche d'informations contenues dans la bd (catégories, genres, jeux),
- la création, édition, suppression d'un jeu.
La base de données a la structure suivante :
Principes généraux, fonctionnalités
- La partie consultation permet l'accès à plusieurs vues :
- liste d'ensemble des catégories et genres de jeux (sous forme de lien),
- détails d'une catégorie et d'un genre avec la liste de ses jeux (sous forme de lien),
- détails d'un jeu (les genres et catégories du jeu sont des liens).
- La partie modification permet, pour un jeu :
- l'édition (sans modification du poster)
- la création (poster facultatif)
- la suppression
- Tri des listes de jeux par titre ou par année
- fonction de recherche textuelle
Contraintes de réalisations
- Votre code utilisera codeigniter v3, exactement comme en TP.
- Vous utiliserez le serveur de base de données mariaDB de l'iut, comme en TP.
- Vous travaillerez seul, ou en binôme, à l'intérieur de votre groupe de TP.
- Vous créerez un dépot GIT par monôme/binôme, avec le nom sae_r301_grx (
x\in\{12,34,56\}) suivant votre groupe TP. Ulysse Jarnouen et Denis Monnerat seront collaborateurs. - Votre dépot contiendra un fichier README.md, avec :
- le prénom, nom des membres du binômes
- l'url de votre site sur dwarves.iut-fbleau.fr
Usage de l'IA
L'IA est autorisée mais ne remplace pas la compréhension
Le recours a l'IA peut être autorise comme outil d'assistance, au même titre qu'une documentation, un forum technique ou un IDE. En revanche :
- tout code rendu doit être compris par l'étudiant;
- tout code non expliqué ou non modifiable en situation sera considéré comme non acquis;
- l'étudiant reste responsable de la qualité, de la sécurité et de la cohérence du code rendu.
Règles communes concernant l'usage de l'IA
- L'usage de l'IA est autorisé comme outil d'assistance.
- Tout code rendu doit pouvoir être expliqué et modifié par l'étudiant.
- Les propositions de l'IA doivent être relues, testées et adaptées.
- Un code non compris ou non maitrise pourra être considére comme non acquis.
- La transparence sur l'usage de l'IA est attendue dans le journal de bord, dans le dépôt et en soutenance.
Exemple de contenu attendu dans le journal sur la partie "Usage de l'IA":
- les prompts utilisés;
- les extraits de réponse juges utiles;
- ce qui a été retenu, adapte ou rejeté;
- les vérifications effectuées après usage.
Organisation générale de l'évaluation
Workflow de travail attendu
Afin de structurer le travail, de faciliter le suivi, le projet devra s'appuyer sur un workflow Git simple et obligatoire.
Pour chaque séance :
- Vous devrez créer une branche de travail dédiée a la séance;
- Vous devrez pousser régulièrement vos modifications sur cette branche au cours de la séance ;
- en fin de séance, vous devrez ouvrir une "Pull Request" vers la branche cible définie (main) pour le projet;
- Vous devrez assigner cette Pull Request a l'enseignant;
- L'enseignant examinera et approuvera la Merge Request pour valider le travail réalisé ;
- une fois la Merge Request approuvée, vous pourrez procéder au merge.
Il est recommandé que les messages de commit et les titres de Merge Request soient explicites et lies a l'objectif technique traité.
Traces de progression
Voici une liste d'éléments qui prouveront votre progression :
- dépôt Git avec commits réguliers;
- journal de bord court a chaque séance;
- liste des taches réalisées et reste a faire;
- tableau de répartition des responsabilités.
Le journal de bord doit suivre une structure simple et identique pour tous les groupes. Il peut rester concis, mais il doit être présent a chaque séance. Structure recommandée pour chaque séance :
- objectif de la séance;
- travail réalisé;
- difficultés rencontrées;
- décisions prises ;
- travail de chacun dans le binôme;
- points a reprendre a la séance suivante;
- usage de l'IA, si applicable.
Le journal de bord doit être conservé dans un fichier Markdown (JOURNAL.md) du dépôt afin de rester consultable avec le reste des traces du projet.
Évaluation
- L'avancement de votre travail sera mesuré à chaque fin de séance de TP (4 semaines).
- Votre réalisation sera évalué la semaine du 15 juin.
- Tout dépot avec quelques commits récents se verra fortement pénalisé.
- Un coefficient multiplicateur de 0 à 1 sera appliqué pour refléter l'équilibre du travail entre les deux membres du binôme.
La note ne repose pas uniquement sur le livrable final
Une application fonctionnelle ne suffit pas a prouver l'acquisition des compétences. L'évaluation reposera sur plusieurs types de preuves :
- un livrable fonctionnel;
- des traces de progression;
- une explication orale individuelle;
- une courte mise en situation technique en direct.
Quand le projet est réalisé en binôme, une partie de la portera sur le travail collectif. Chaque étudiant doit notamment être en mesure d'expliquer un extrait de code introduit ou modifié par son binôme.