1°/ Constitution des groupes et choix du sujet
- Les groupes doivent être constitués de 5 étudiants (sauf exception à 4 à cause du nombre d'étudiants), peu importe les groupes de TD/TP
- En cas de litige ou problèmes pour former les groupes, l'équipe pédagogique se donne le droit de constituer arbitrairement certains groupes.
- Chaque groupe constitué doit choisir un des 2 types de sujet et en préciser le contexte (cf. ci-dessous)
- Les 2 types de sujet sont décrits dans les articles :
|
ATTENTION ! Chaque groupe constitué en S3 continuera avec les mêmes membres et le même sujet en S4. En effet, le cahier des charges donné dans la description des sujets contient des tâches qui seront suffisamment conséquentes pour nécessiter le S3 et le S4 comme période de développement. Ces cahiers des charges précisent les attendus minimaux en fin de S3, qui ne couvrent pas totalement les fonctionnalités attendues. L'objectif n'est donc pas de réaliser entièrement l'application au S3 mais de compléter ce qui manque au S4. Cela donnera l'occasion de voir si les choix de conceptions de votre application permettent de lui ajouter facilement des fonctionnalités. |
2°/ Organisation du travail
2.1°/ sujet type 1 - orienté full stack
- L'organisation des cours de S3 permettent d'apprendre en parallèle comment créer le front et le back d'une application web.
- Il est donc possible de commencer le développement de ces 2 parties quasi en même temps, une fois que le cahier des charges est pleinement défini.
- En revanche, l'accès d'un serveur node à une BdD SQL est abordé en seconde partie du semestre 3. Il n'est donc pas possible d'implémenter ces accès dès le début de la SAÉ. En revanche, il est parfaitement possible de modéliser dès le début la BdD en définissant quelles tables sont utiles, avec quels champs.
- Compte tenu de ces contraintes, voici un suggestion de découpage du travail :
- création d'un cahier des charges détaillé, c.a.d. qui fixe le cadre du projet (type manifestation, prestataire, ...) aussi bien du point de vue fonctionnel (quels services, quelles statistiques, ...) que les données manipulées (informations liées aux prestataires, services, ...)
- création du modèle de données pour la BdD, puis une fois stabilisé des scripts de création de la BdD. L'idéal est de commencer par les données communes à tout projet : informations utilisateur, données de gestion de la carte interactive puis de s’intéresser aux données liées aux services.
- définition des requêtes possibles donc des routes de l'API en fonction des fonctionnalités de l'application. Cela signifie qu'il faut définir le type de requête HTTP, ainsi que le format de la route. Les premières routes à définir concernent la gestion des utilisateurs puis celles de la carte, pour terminer avec les services et les statistiques.
- création du modèle de données pour la communication entre le front-end et l'API. Lors d'une requête vers une route, ces deux parties vont s'échanger des objets JSON. Il faut donc définir leur contenu. Par exemple, lorsque que l'utilisateur veut s'authentifier, le front-end doit envoyer une requête au serveur API. Cette requête est forcément accompagnée d'un objet JSON contenant au minimum un champ pour le login, et un pour le mot de passe. Il faut donc définir précisément la structure de cet objet : nom des champs, type des champs, optionnels ou non, etc. Ensuite, le serveur procède à l'authentification et va retourner un objet résultat au front-end. Il faut également définir la structure de cet objet. Ces définitions sont à écrire pour chacune des requêtes/routes possibles.
- création d'un fichier contenant des objets JSON faisant office de source de données pour l'API et le front-end (comme vu dans les cours de dev. Web). Ces fichiers contiennent tout simplement des objets dont le format correspond à ce qui devrait être renvoyé à l'API lorsque cette dernière fait des requêtes sur la BdD, et à ce qui est envoyé au front-end par l'API (NB: qui n'est pas forcément la même chose que ce qui est récupéré en BdD). Par exemple, ces fichiers vont contenir des objets représentant les données renvoyées lors d'une authentification, une liste représentant des prestataires bidons, etc.
- implémentation de l'API en écrivant des fonctions de traitement des requêtes qui vont récupérer des données dans le fichier mentionné ci-dessus, plutôt que dans la BdD pas encore stabilisée. Les premières fonctions à écrire concernent la gestion des utilisateurs, puis celles de la carte, pour terminer avec les services et les statistiques.
- Implémentation du front-end. Là encore, la source de données est le fichier mentionné en 5.
- modification des fonctions de l'API traitant les requêtes pour aller chercher les données en BdD.
2.2°/ sujet type 2 - orienté manipulation de données
- L'organisation du travail pour ce type de sujet est globalement le même qu'avec le type 1, excepté qu'il y a des tâches supplémentaires, notamment liées à la récupération des données manipulées par l'application :
- création d'un cahier des charges détaillé, c.a.d. qui fixe le cadre du projet (objectif du site, type d'informations, ...) aussi bien du point de vue fonctionnel (quelles statistiques affichables, tris/filtres, ...) que les données manipulées (source initiale, pré-traitements, ...)
- récupération des données auprès des sources (par ex au format csv), puis écriture de scripts permettant des traiter ces données : nettoyage, agrégation, production d'images statiques, etc.
- création du modèle pour la BdD, puis une fois stabilisé des scripts de création de la BdD. Ce modèle doit inclure les tables nécessaire pour stocker les données mentionnées en 2, mais aussi celles qui contiennent des données de gestion de l'application, comme par exemple les informations utilisateur.
- importation des données du 2 dans la BdD, sous la forme de script (python, shell, ...)
- définition des requêtes possibles donc des routes de l'API en fonction des fonctionnalités de l'application. Cela signifie qu'il faut définir le type de requête HTTP, ainsi que le format de la route. Les premières routes à définir concernent la gestion des utilisateurs (inscription, login, modification profil, etc.), puis celles qui permettent de récupérer des données de façon paramétrée depuis la BdD.
- création du modèle de données pour la communication entre le front-end et l'API. Lors d'une requête vers une route, ces deux parties vont s'échanger des objets JSON. Il faut donc définir leur contenu. Par exemple, lorsque que l'utilisateur veut s'authentifier, le front-end doit envoyer une requête au serveur API. Cette requête est forcément accompagnée d'un objet JSON contenant au minimum un champ pour le login, et un pour le mot de passe. Il faut donc définir précisément la structure de cet objet : nom des champs, type des champs, optionnels ou non, etc. Ensuite, le serveur procède à l'authentification et va retourner un objet résultat au front-end. Il faut également définir la structure de cet objet. Ces définitions sont à écrire pour chacune des requêtes/routes possibles.
- création d'un fichier contenant des objets JSON faisant office de source de données pour l'API et le front-end (comme vu dans les cours de dev. Web). Ces fichiers contiennent tout simplement des objets dont le format correspond à ce qui devrait être renvoyé à l'API lorsque cette dernière fait des requêtes sur la BdD, et à ce qui est envoyé au front-end par l'API (NB: qui n'est pas forcément la même chose que ce qui est récupéré en BdD). Par exemple, ces fichiers vont contenir des objets représentant les données renvoyées lors d'une authentification, une liste représentant des prestataires bidons, etc.
- implémentation de l'API en écrivant des fonctions de traitement des requêtes qui vont récupérer des données dans le fichier mentionné ci-dessus, plutôt que dans la BdD pas encore stabilisée. Les premières fonctions à écrire concernent la gestion des utilisateurs, puis celles de la carte, pour terminer avec les services et les statistiques.
- Implémentation du front-end. Là encore, la source de données est le fichier mentionné en 7.
- modification des fonctions de l'API traitant les requêtes pour aller chercher les données en BdD.
2.3°/ Remarques
- En fin de S3, le front-end DOIT pouvoir être ENTIÈREMENT testé sans nécessiter que l'API existe et soit lancée, d'où le recours à des fichiers de données sources, comme vu en cours.
- Cependant, rien n'interdit de commencer à écrire et tester du code pour la connexion à l'API dès le S3 (NB: Il y aura d'ailleurs un CM sur ce sujet après la toussaint). Toutefois :
- ce code ne doit pas être utilisé/appelé dans ce qui sera rendu pour l'évaluation du S3,
- ce code ne sera pas pris en compte comme "bonus" dans l'évaluation.
- En fin de S3, l'authentification des utilisateurs n'a pas besoin d'être "sécurisée". Un mécanisme minimal est proposé dans les sujets. En revanche, une authentification et une sécurisation des communication à base de sessions et/ou jwt devra ajoutée en S4.
- D'un point de vue temporel, il va de soi que certaines tâches vont évoluer en parallèle afin que tous les membres soient occupés.
- Par exemple, pendant que certains s'occupent de modéliser et créer les tables concernant les utilisateurs, d'autres peuvent commencer la modélisation des échanges entre API et front
- Quand ces tâches ont suffisamment avancé, il est possible de commencer en parallèle les tâches de développement du front et du back.
3°/ Référents
Pour simplifier la gestion des questions concernant la SAÉ, des référents enseignants ont été désignés pour chaque domaine technique abordé dans le projet.
- API : Joseph Azar,
- front-end : Stephane Domas,
- BdD : David Laiymani, Jospeh Azar,
- extraction, analyse et visualisation des données : Hassan Noura
- gestion/suivi de projet : Fabrice Ambert,
Pour le sujet de type I, il est également recommandé de faire appel à Karine Deschinkel pour tout ce qui concerne les méthodes/algorithmes pour la création automatisée des emplacements prestataire, planning, trajet, ...
Pour des questions relatives à l'organisation générale du projet (planning, délivrables, ...), posez vos questions de préférence par mail, en écrivant aux 5 premiers enseignants de la liste ci-dessus. On se chargera d'élaborer une réponse collective à votre demande.
5°/ Planning (en cours de rédaction donc susceptible de changer)
- lundi 9 septembre 2024 : Réunion de présentation générale,
- jusqu'au lundi 16 septembre : constitution des groupes, choix des contextes des sujets.
- jeudi 19 septembre : chaque groupe présente (devant l'équipe d'enseignants chargés du suivi) son projet en décrivant le type de sujet choisi et son contexte. Par exemple, pour le sujet de type 1, cela implique de présenter le type de manifestation, les informations liées aux prestataires, les services, les statistiques, ... et pour le sujet de type 2, de présenter les types de données sources, le type de graphique qui peut être visualisé, ... c.a.d. tout ce qui est laissé libre de choix dans le cahier des charges. Les enseignants valideront le projet tel quel ou bien feront des ajustements pour augmenter/réduire la difficulté.
- toutes les semaines : suivi (en méthode agile) d'un certains nombre de projets (avec F. Ambert), sachant qu'un projet donné est évalué toutes les 2 semaines.
- fin du semestre 3, deuxième évaluation : délivrables décrits en partie 6.2 + soutenance.
6°/ Attendus (en cours de rédaction donc susceptible de changer)
6.1°/ Présentation du projet : jeudi 19 septembre.
Selon le type de sujet choisi, le contenu des transparents de la présentation vont différer un peu, mais la forme est identique : un oral de 5 minutes environ avec un seul orateur.
Pour le sujet de type 1, les points à aborder sont (au minimum) :
- 1 transparent sur le thème et les motivations pour choisir ce thème.
- 1 transparent sur le "cadre géographique" avec éventuellement une première ébauche visuelle de la carte.
- 1 transparent présentant les type de prestataire/activités, avec pour chacun quelque types de besoins logistiques (par ex, dimension emplacement, accès eau/électricité, ...)
- 1 transparent présentant les service fournis, avec pour chacun quelques exemple des données manipulées et/ou collectées.
- 1 transparent présentant les types de statistiques qui seront faites à partir des données collectées de quel(s) service(s), et éventuellement, une idée du visuel
Pour le sujet de type 2, les points à aborder sont (au minimum) :
- 1 transparent sur le thème et les motivations pour choisir ce thème.
- 1 transparent sur les sources de données envisagées, avec quel type de champ vont être récupérés, et quel volume de données
- 1 transparent pour décrire la page d'accueil, avec quel type de graphique dans le carrousel, et éventuellement, une maquette du visuel
- 1 ou 2 transparents pour décrire chacun des types de graphique qui peut être créé dynamiquement et affiché dans le navigateur. Ces transparents doivent décrire :
- les objectifs/intérêt de ces graphiques,
- quelles données doivent être extraites de la BdD pour les produire,
- quels filtres permettent à l'utilisateur de paramétrer cette extraction,
- quels traitement sont faits (sur le serveur ou la navigateur) après l'extraction pour analyser/modifier ces données avant affichage,
- quelle est la forme visuelle du ou des graphiques crées à partir de ces données.
Ensuite, soit le jury validera directement votre projet, soit il fera (à priori plus tard lors des créneaux horaires dédiés aux SAÉ) des remarques sur ce qu'il faudrait ajouter/supprimer. Par exemple, si vous présentez un festival de musique avec une seule scène, cela ne cadre pas avec les fonctionnalités pour la carte interactive. On vous demandera donc de prévoir d'autres emplacements. A l'inverse, si vous prévoyez de faire des services ou produire des graphiques qui sont trop complexes à implémenter, on vous demandera de revoir vos ambitions à la baisse.
6.2°/ Attendus de fin de S3 : première semaine de janvier
6.2.1°/ Rendu numérique
Le rendu doit se faire sous la forme d'une archive contenant tous les items listés ci-dessous, à poser sous moodle. Un lien d'inscription vous sera envoyé lors de la première semaine de janvier.
La date de rendu est le vendredi 10 janvier à 18h00.
Ci-dessous est listé le minimum demandé. Si vous êtes allé plus loin, cela pourra éventuellement être une plus-value pour l'évaluation du S3, mais être un "piège" lors de l'évaluation du S4 car vous aurez moins de progrès à présenter.
ATTENTION ! La plupart des attendus sont communs aux deux types de sujets, mais d'autres sont spécifiques. Dans ce cas, cela est indiqué par un commentaire du type [ seulement pour sujet X ].
Base de données :
- Scripts SQL de création de la base, si vous avez créé la base ainsi. Sinon, rien est à fournir si vous utilisez sequelize pour créer les tables "quand il y a besoin"
- Jeux de données pour remplir les tables, soit sous la forme d'un script SQL, soit sous la forme de code JS appelé lorsque l'API est lancée. NB : au moins un utilisateur administrateur/organisateur doit exister, ainsi que 2-3 utilisateurs de type prestataire/enregistré.
- [ seulement pour sujet 2 ] :
- un document texte décrivant :
- les sources de données "brutes" récupérées,
- les liens vers ces sources,
- la façon de récupérer ces données (scripts ? manipulations utilisateur ? ...),
- leur format,
- les problèmes principaux de ces données (redondance ? formatage ? ...),
- les types de traitement qui ont été appliqués pour les nettoyer.
- si applicable, les scripts pour récupérer les données brutes,
- les scripts permettant de nettoyer et évaluer la qualité des données.
- un document texte décrivant :
API :
- Accès à la BdD fonctionnel,
- Pour toutes les routes triviales nécessaires au fonctionnement de votre application web, le code de traitement de ces routes doit être fonctionnel et interagir avec la BdD. Par triviale, on entend un traitement qui nécessite L'accès en lecture/création/modification de un ou plusieurs éléments dans une unique table (c.a.d. façon CRUD)
- 3-4 routes non triviales doivent également être fonctionnelles. Par non triviale, on entend un traitement qui nécessite de récupérer/mettre à jour des informations en BdD qui sont réparties dans plusieurs tables.
Swagger [ seulement pour sujet 1 ] :
- Les routes triviales, ainsi que les 3-4 routes non triviales doivent être documentées et testables via swagger
Front-end vuejs :
- Le visuel peut utiliser du HTML basique du moment que l'application est fonctionnelle. Il n'y a donc aucune contrainte sur le fait d'utiliser vuetify, ou du CSS pour améliorer le visuel (NB : cela sera cependant demandé en S4)
- La source de données peut être locale (comme vu en TP). Il n'y a donc aucune obligation d'interroger réellement l'API.
- Les principes de navigation générale dans l'application doivent être fonctionnel, notamment la possibilité de changer de rôle, ainsi que l'affichage de menus pour accéder aux fonctionnalités en fonction du rôle de l'utilisateur.
- L'authentification doit donc être fonctionnelle quand bien même ce n'est pas sécurisé et purement local. Par fonctionnelle, on entend le fait que l'application peut changer de "mode" selon le rôle de l'utilisateur authentifié.
- [ seulement pour sujet 1 ] : par rapport au cahier des charges complet, voici ce qui est demandé au minimum selon les rôles.
- La partie accessible par le public doit afficher la carte interactive avec des informations qui apparaissent (localisation et mode laissé libre : encart, infobulle, dialogue, ...) quand on survole une zone associée à un prestataire.
- Au moins un prestataire doit exister et la carte interactive permet d'accéder à l'espace de ce prestataire (NB : en restant mode public).
- Cet espace prestataire doit permettre d'accéder à 2 services publics "faciles" à implémenter (par ex, livre d'or, contact, ...) et un moyennement facile (par ex, réservation de séance). Ces services doivent être fonctionnels quand bien même les données saisies ne vont pas en BdD. Il faut donc prévoir des fonctions permettant d'ajouter des données à la source locale.
- Quand un prestataire est logué, aucune fonctionnalité de gestion de ses informations ou de ses services (création/suppression) n'est demandé. En revanche, la partie prestataire des 2 services faciles et du service moyen doivent être fonctionnels. Par exemple, si le public peut signer un livre d'or, le prestataire doit pouvoir visualiser les commentaires. Si le public peut réserver une séance, le prestataire peut voir la liste des réservations. etc.
- Quand un administrateur est logué, aucune fonctionnalité de gestion des informations de l'événement ou bien des prestataires n'est demandé. Seul les menus doivent changer pour permettre d'accéder à ces fonctionnalités.
- [ seulement pour sujet 2 ] :
- La partie accessible par le public doit afficher au minimum le carrousel.
- Les fonctionnalités attendues pour les rôles "utilisateur authentifié" et "administrateur" sont décrites directement dans le sujet.
- Fournir les scripts permettant de créer les images pour le carrousel de la page d'accueil.
6.2.2°/ Rendu oral : jeudi 9 - vendredi 10 janvier
La forme est une soutenance entre 20 et 25 minutes, démonstration comprise. Les transparents de la soutenance doivent également être déposés sous moodle, dans le même cours que le rendu numérique, mais dans un dépôt différent. La date limite de dépôt des transparents est également vendredi 10 janvier à 18h.
Voici les points à aborder :
- présentation de l'application avec le cadre, les fonctionnalités générales, ... c.a.d. un résumé mis à jour de la soutenance de présentation initiale.
- [ seulement pour sujet 2 ] : un résumé rapide des sources de données qui ont été utilisées, les éventuels problèmes dans ces données et les traitements qui ont été appliqués pour les nettoyer, préparer avant mise en BdD.
- 3 scénarios d'utilisation de l'application, avec comme acteur une personne du public, un prestataire/utilisateur enregistré et un administrateur. Ces scénarios doivent être illustrés par différents documents graphiques tels que des storyboards, des diagrammes de séquence, des maquettes d'interface etc.
- démonstration :
- [ seulement pour sujet 1 ] : doit présenter les fonctionnalités liées à un utilisateur public et prestataire, en s'appuyant sur les scénarios.
- [ seulement pour sujet 2 ] : doit présenter les fonctionnalités liées à un utilisateur enregistré ainsi que la partie gestion utilisateur de l'administrateur, en s'appuyant sur les scénarios.
- bilan d'avancement du projet avec comme support un burn-up chart, et bilan fonctionnel que ce qui est implémenté (avec %) et ce qui reste à faire.
- commentaire sur des faits marquants lors de la conception de la BdD, illustrant par exemple la difficulté de modéliser sans avoir défini précisément et/ou correctement les scénarios d'utilisations.
- un plan pour la prochaine version, avec pour chaque "sprint" les fonctionnalités principales à intégrer.