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 contexte pour le type de sujet qui est imposé à tous les étudiants et décrit dans l'article :
|
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 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°/ 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,
- gestion/suivi de projet : Fabrice Ambert,
- extraction, analyse et visualisation des données : [ à définir ]
Enfin, 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)
- vendredi 12 septembre 2024 : Réunion de présentation générale,
- jusqu'au vendredi 19 septembre : constitution des groupes, choix des contextes des sujets.
- vendredi 26 septembre : chaque groupe envoie un mini-document présentant son projet en décrivant le type de sujet choisi et son contexte. Par exemple, cela implique de présenter le type de manifestation, les informations liées aux prestataires, les services, les statistiques, ... Les enseignants référents valideront le projet tel quel ou bien feront des ajustements pour augmenter/réduire la difficulté. Dans ce cas, ces ajustements vous seront communiqués lors des séances bi-hebdomadaires (cf. ci-dessous)
- 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 : vendredi 26 septembre.
Le mini-rapport de présentation du sujet doit aborder les points suivants (au minimum) :
- le thème et les motivations pour choisir ce thème.
- le "cadre géographique" avec éventuellement une première ébauche visuelle de la carte.
- les type de prestataire/activités, avec pour chacun quelque types de besoins logistiques (par ex, dimension emplacement, accès eau/électricité, ...)
- les service fournis, avec pour chacun quelques exemple des données manipulées et/ou collectées.
- 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
La forme est laissée libre, mais doit respecter les attendus basiques d'un rapport (page de garde avec titre/participants/...), sommaire, glossaire, 4ème de couverture, ...
Ce rapport sera à déposer au plus tard le vendredi 26 septembre 23h59 sous moodle. Un lien et les modalités d'inscription seront communiquées par mail.
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 9 janvier à 23h59.
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.
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é.
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 :
- 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é.
- 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.
6.2.2°/ Rendu oral : jeudi 8 - vendredi 9 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 9 janvier à 23h59.
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.
- 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 : doit présenter les fonctionnalités liées à un utilisateur public et prestataire, 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.