Jérôme Cutrona

Version statique de l'intranet de Jérôme Cutrona - Rejoindre la version dynamique 🔒

Certains exemples et corrections sont susceptibles de ne pas être opérationnels.

B.U.T. Informatique - IUT de Reims - Université de Reims

SAÉ 5.Real.01 - Développement avancé

Navigation

Apprentissages critiques

  • Choisir et implémenter les architectures adaptées
  • Intégrer des solutions dans un environnement de production
  • Anticiper les résultats de diverses métriques (temps d’exécution, occupation mémoire, montée en charge...)
  • Choisir et utiliser des bibliothèques et méthodes dédiées au domaine d’application (imagerie, immersion, intelligence artificielle, jeux vidéos, parallélisme, calcul formel...)
  • Organiser et partager une veille technologique et informationnelle

Introduction

Cette SAÉ reproduit la problématique professionnelle consistant à créer, en équipe, une application en suivant une démarche itérative ou incrémentale. Vous allez donc réaliser une application en équipe de 5 ou 6, en suivant une méthode de travail agile, en utilisant les nouvelles technologies et les nouveaux outils de développement avancés vus ce semestre.

Versionnage du projet

Vous travaillerez en équipe de 5 à 6. L'un des membres aura la charge de créer les dépôts GitLab qui seront nommés « sae5-01-front » et « sae5-01-back ». Dans les dépôts, la collaboration entre les membres du groupe suivra les mêmes règles que celles présentées dans le TP « Collaboration avec Gitlab » :

  • Un fichier « README.md » présentera le nom, prénom et login des membres du groupe ainsi que les grandes lignes du projet et de sa mise en place
  • La branche principale sera protégée, aucun commit direct ne sera autorisé
  • Vos productions seront faites sous forme de branches qui seront soumises à la revue de code de vos partenaires et fusionnées lorsqu'elles sont considérées admissibles
    Information

    Veillez à rebaser votre branche avant de la soumettre à la fusion (« merge request ») afin de limiter les conflits.

  • Chacun des membres du groupe sera noté sur tous les aspects du projet et devra donc contribuer autant au front qu'au back
  • L'équilibre entre les contributions des membres du groupe sera considéré dans les deux dépôts
    Remarque importante

    La note de chacun des partenaires sera proportionnelle à la quantité et la qualité de ses contributions, dans chacun des deux dépôts.

  • Chaque commit sera le plus ciblé possible
    Remarque importante

    Tout commit qui ne respecte pas les règles, car il apporte trop de fichiers et/ou trop de nouveautés en une seule fois, sera sanctionné.

    En dehors de la mise en place du projet et de l'ajout de ressources externes, un commit doit introduire en une fois un seul des éléments suivants :

    • Une installation de bundle
    • Une modification de configuration
    • Une entité
    • Un jeu d'essai (« fixtures », forge)
    • Un jeu de tests
    • La création d'un contrôleur et de la vue associée
    • Une fonctionnalité particulière

    L'interface de gestion de versions PhpStorm propose d'effectuer un commit sur une partie des fichiers modifiés. Utilisez cette fonctionnalité pour structurer vos commits.

  • Chaque message de commit, rédigé en anglais, sera clair et explicite et suivra les règles des commits conventionnels
  • Vous veillerez à ce que vos nom et prénom réels et mail universitaire soient configurés dans git de façon identique à l'IUT et sur votre ordinateur personnel

Découpage du projet

Votre application va proposer une interface utilisateur s'appuyant sur Symfony et sur React avec des données manipulables à travers une API Web. L'ensemble des services sera mis en place sous forme de conteneurs.

Quantité de travail engagée

Cette SAÉ est prévue sur 6 semaines à temps plein (39, 40, 43, 44, 47 et 48) pour un total de 150 heures de travail individuel supervisé auxquelles viennent s'ajouter 30 heures de travail encadré. Vous devrez donc vous organiser pour travailler en moyenne 30 heures par semaine, en équipe et en autonomie. Le projet est conséquent (750 à 900 heures de travail en tout) et vous devez le mener à bien. Afin de refléter parfaitement les conditions professionnelles, le client pourra être amené à réviser ses besoins en cours de projet.

Méthode de travail : agile

Vous mettrez en pratique la méthode agile pour la gestion de votre projet. Vous effectuerez la planification dans Microsoft Planner avec une suggestion forte pour cette organisation :

  • Un à deux sprints par semaine
  • Une à deux réunions de sprint par semaine (une heure) pour définir les objectifs et éventuellement faire un bilan du sprint précédent
  • Daily (une réunion par jour comme son nom l'indique) pendant laquelle chaque membre présente :
    • Travail effectué
    • Travail à faire
    • Problèmes rencontrés
    Cette réunion se fera obligatoirement en présence de l'intervenant de SAÉ lorsqu'une heure encadrée est prévue dans l'emploi du temps
  • Proposition de découpage des états du Kanban :
    • « Backlog »
    • À faire
    • En cours
    • « Merge request »
    • Revue de code en cours
    • Fait

Afin de leur permettre de suivre votre avancement, vous ajouterez les enseignants de la SAÉ dans votre planification Microsoft Planner dès le début du projet.

Traduction des besoins du client

L'application que vous devez réaliser part d'un besoin exprimé par un client de manière imprécise et incomplète. Vous devez donc traduire ce besoin en fonctionnalités et en contraintes techniques. Vous devez également vous projeter dans la réalisation de l'application en vous appuyant sur les nouvelles ressources vues ce semestre. Vous partirez des éléments ci-après et vous aurez le loisir de questionner le client pour obtenir des précisions. L’objectif est de clarifier ou compléter, collecter et formaliser le besoin puis de développer une application communicante intégrant la manipulation des données et respectant les paradigmes de qualité.

Le département informatique de l'IUT de Reims souhaite pouvoir organiser des chasses au trésor pour les étudiants. Chaque chasse au trésor est constituée d'un ensemble d'énigmes. Chaque énigme est associée à un lieu géographique (un bâtiment, une salle, un monument, etc.) décrit par un texte ou présenté par une image. Le lieu peut être géolocalisé. Les énigmes peuvent être de différents types :

  • texte libre
  • QCM
  • scan d'un QR Code
  • passage à proximité d'un lieu selon le GPS
  • tout autre type d'énigme pertinent que vous pourrez imaginer

Les étudiants doivent s'inscrire à une chasse au trésor pour la réaliser individuellement. Lorsqu'ils trouvent la solution d'une énigme, ils la soumettent via l'application. Si la solution est correcte, le temps de résolution de l'énigme est mémorisé et ils peuvent passer à l'énigme suivante. Si la solution est incorrecte, un malus de temps est appliqué. S'ils ne passent pas à l'épreuve suivante, la chasse au trésor est mise en pause. L'application doit également permettre aux organisateurs de créer et gérer les chasses au trésor, les énigmes et les utilisateurs.

Vous traduirez l'ensemble de ces besoins en documents d’analyse et de conception : use cases, détails des actions possibles, maquettes de toutes les pages, MCD compatible avec Doctrine, jeu d'essai, etc.

Quelques éléments concernant les concepteurs de chasses au trésor

Les concepteurs de chasses au trésor :

  • pourront s'inscrire, se connecter et se déconnecter
  • pourront créer, modifier, supprimer et consulter des chasses au trésor et les énigmes qui les composent
  • pourront créer, modifier, supprimer et consulter des utilisateurs
  • pourront consulter les résultats des participants aux chasses au trésor
  • pourront consulter et modifier leur profil
  • sont groupés par équipes de conception
  • auront des rôles et des permissions dans l'application
  • ne pourront pas consulter ou modifier les chasses au trésor conçues par les autres équipes
  • ne pourront pas s'inscrire à une chasse au trésor conçue par leur équipe

Quelques éléments concernant les participants aux chasses au trésor

Les participants aux chasses au trésor pourront :

  • s'inscrire, se connecter et se déconnecter
  • consulter la liste des chasses au trésor disponibles
  • s'inscrire à une chasse au trésor
  • ne pourront consulter que l'énigme en cours de la chasse au trésor à laquelle ils sont inscrits
  • soumettre une réponse à l'énigme en cours
  • consulter leur score et l'énigme suivante lorsqu'ils auront trouvé la bonne réponse
  • consulter la liste des chasses au trésor auxquelles ils sont inscrits et leur progression dans chacune d'elles
  • consulter leur profil et modifier certaines informations les concernant

Style et langue de codage

Vous respecterez les règles de style de codage de Symfony et de React, vous vous appuierez sur les outils de vérification de code étudiés et automatiserez leur exécution dans le cadre de l'intégration continue. Vous veillerez à la qualité de votre code, à sa lisibilité et à sa maintenabilité.

Vous coderez intégralement en anglais :

  • classes CSS
  • classes, méthodes, propriétés, variables, … en PHP
  • routes, paramètres de routes, contrôleurs, actions, entités, propriétés, … en Symfony
  • fichiers, dossiers, fonctions, variables … en JavaScript
  • composants, props, states, contextes, … en React
  • « fixtures », « Cest », classes de test, méthodes de test, … pour les tests
  • images, volumes, … en Docker

Les interfaces utilisateur seront en français.

Aspects techniques

Cette SAÉ permet de mettre en pratique les technologies apprises tout au long du B.U.T. mais également les nouvelles compétences acquises ce semestre. Vous devrez donc utiliser les technologies suivantes :

  • HTML, CSS
  • Symfony, PHP
  • API Platform, EasyAdmin
  • React, JavaScript
  • Docker
  • Symfony avancé
  • React avancé
  • Intégration continue

Certaines technologies seront imposées pour certaines parties de la SAÉ afin d'évaluer l'ensemble des compétences à acquérir ce semestre.

Interface pour les concepteurs de chasses au trésor et API Web

La partie de l'application dédiée aux concepteurs de chasses au trésor sera réalisée en Symfony et s'appuiera sur une API Web qui exposera le modèle de données de la façon la plus appropriée possible. Une reflexion sur la pertinence, la performance, la sécurité et la validation par les tests conduira aux choix les plus judicieux.

Vous vous appuierez principalement sur les ressources « R4.01 | Architecture logicielle », « R4.02 | Qualité de développement » et « R5.15-R.516-R5.17 | Symfony avancé / Intégration continue ».

  • L'API Web sera basée sur Symfony et API Platform et respectera les bonnes pratiques
  • Les accès authentifiés à l'API Web seront gérés à l'aide de JWT
  • Le moteur de base de données sera PosgreSQL
  • Le projet comportera des données, factices et non factices, sous formes de « fixtures »
  • Des tests permettront de vérifier le bon fonctionnement et la sécurité de l'application dédiée aux concepteurs ainsi que de l'API
  • Une interface d'administration complémentaire pourra être réalisée à l'aide de EasyAdmin
  • Des règles de sécurité limiteront l'accès aux données
  • Les aspects UI/UX seront soignés pour proposer la meilleure expérience possible

Interface utilisateur pour les participants aux chasses au trésor

La partie de l'application dédiée aux participants aux chasses au trésor sera réalisée en React et s'appuiera sur l'API Web

Vous vous appuierez principalement sur les ressources « R4.Real.10 | Complément web », « R4.01 | Architecture logicielle » et « R5.05R | React avancé / PWA ».

  • L'interface utilisateur respectera les bonnes pratiques
  • La navigation se fera à l'aide d'un système de routage
  • L'application sera pensée « mobile first » et fera usage des « media queries » pour proposer un affichage correct quelle que soit la largeur d'affichage
  • Les mises en forme CSS devront au maximum utiliser « flexbox »
  • L'accessibilité et l'ergonomie feront l'objet de toutes les attentions
  • L'interface devra être structurée en composants indépendants
  • Les composants interagiront avec l'API
  • Les aspects UI/UX seront soignés pour proposer la meilleure expérience possible

Charte graphique et style

L'application pour les participants s'appuiera sur un design sobre, cohérent, « mobile first » et responsive. Dans tous les cas, vous utiliserez un toolkit CSS pour vous faciliter la tâche. Vous pourrez utiliser Sass pour simplifier la gestion des feuilles de style et/ou personnaliser le toolkit.

L'application pour les concepteurs pourra s'appuyer sur le même design que l'application pour les participants ou en adopter un autre, à condition qu'il soit cohérent, « mobile first » et responsive. Vous pourrez également utiliser un toolkit CSS pour vous faciliter la tâche. Vous pourrez utiliser Sass pour simplifier la gestion des feuilles de style et/ou personnaliser le toolkit.

Application sous forme de conteneurs

L'application finale sera déployée sous forme d'un conteneur Docker, contenant l'application Symfony, l'API et l'interface utilisateur.

Vous vous appuierez principalement sur la ressource « R4.Real.08 | Virtualisation ».

  • Tous les services de l'application seront portés par une pile de conteneurs
  • La procédure de démarrage sera documentée

Intégration continue

Dès que vous aurez réalisé l'intégration continue dans le TP « R5.15-R.516-R5.17 | Symfony avancé / Intégration continue », vous créerez une machine virtuelle, la configurerez pour en faire un « runner » GitLab et l'associerez au dépôt GitLab de votre SAÉ.

Afin de permettre à chaque membre du groupe d'intervenir sur la machine virtuelle, vous créerez un jeu de clé SSH qui sera dédié à la connexion sur la machine virtuelle :

ssh-keygen -t rsa -f ~/.ssh/id_rsa_sae501
Vous pourrez alors ajouter les clés SSH des membres du groupe dans le fichier ~/.ssh/authorized_keys de la machine virtuelle.

Rapport de projet en français

Vous présenterez votre réalisation par écrit en français. Vous effectuerez un résumé du sujet, présenterez brièvement ce que votre application apporte à l'utilisateur puis détaillerez votre réalisation avec les contributions de chacun dans un compte-rendu de groupe.

En annexe, vous ajouterez des copies de votre Microsoft Planner, ainsi que le CV (de chacun des membres du groupe) à jour dans lequel cette SAÉ sera valorisée.

Vous respecterez les règles de présentation d'un dossier tant au niveau du fond (synthèse et analyse, style informatif, précis et dense, maîtrise de la syntaxe et de l'orthographe notamment) que de la forme (organisation claire en parties et sous-parties, table des matières, police sans serif de taille 12, interlignes simples, pagination en haut à droite, pied-de-page mentionnant sur une première ligne le Prénom et le NOM de chaque membre du groupe et sur une deuxième ligne | B.U.T. Informatique | SAÉ 5.01|, titres et numérotation des annexes, soin de la page de couverture incluant notamment les logos de l'IUT RCC et des départements Info).

Information

Utilisez les outils de gestion des documents longs dans Microsoft Word pour vous simplifier la tâche.

Des heures seront prévues dans l'emploi pour vous guider dans la rédaction du rapport.

Présentation orale aux clients / collègues en anglais

Vous présenterez votre réalisation en anglais comme si vous la livriez à un client ou la présentiez à des collègues de travail. Vous effectuerez un résumé du sujet et vous présenterez ce que votre application apporte à l'utilisateur. Les aspects techniques seront donc limités et vous mettrez l'accent sur les fonctionnalités proposées, les efforts d'ergonomie et d'accessibilité, les aspects environnementaux ainsi que les évolutions possibles de votre produit.

  • La présentation sera agrémentée d'un support
  • Chaque membre du groupe devra intervenir à l'oral
  • Le temps de parole sera équitablement partagé
  • Une démonstration sera réalisée sous forme de vidéo (ou en temps réel à condition qu'elle suive un script prévu dans le détail)
  • Vous analyserez les améliorations et les évolutions possibles de votre application
  • Votre intervention durera 15-20 minutes
  • Le jury vous posera des questions pendant 10-15 minutes

Des heures seront prévues dans l'emploi du temps pour vous guider dans la préparation de cette présentation.

Déroulement, suivi et évaluation

Le précédent découpage constitue la liste des livrables. Vous réaliserez plusieurs étapes en parallèle et maximiserez votre efficacité en vous répartissant le travail. Votre intervenant de SAÉ jouera le rôle de client et répondra à vos questions concernant les besoins.

Déroulement

Vous devrez collecter les besoins et documents fournis pour constituer le dossier d'analyse et de conception. Vous déciderez ensuite des fonctionnalités à réaliser et de leur ordre de priorité. Vous construirez la base de données et le jeu d'essai issu des données factices. Vous pourrez alors commencer à mettre en place l'API Web, le back-office en Symfony et l'interface utilisateur en React. Vous pourrez également commencer à réfléchir à la mise en place des conteneurs.

La présentation orale en anglais aura lieu la dernière semaine. Vous remettrez votre rapport de projet au moment de la présentation.

Suivi

Antoine Jonquet et Jérôme Cutrona seront vos intervenants de SAÉ ainsi que vos référents techniques pour les aspects front et back. Vous pourrez solliciter les autres intervenants des matières informatiques et non informatiques pour des conseils ponctuels.

Vous ajouterez vos référents dans la planification Microsoft Planner dès le début du projet.

La réunion quotidienne se fera obligatoirement en présence de l'intervenant de SAÉ lorsqu'une heure encadrée est prévue dans l'emploi du temps

Évaluation

La réalisation générale conduira à une note qui sera évidemment individualisée en fonction des contributions de chacun. La qualité du travail et le respect des consignes de réalisation sont tout aussi importants que la réalisation en elle-même.

Votre travail d'équipe sera évalué à travers la mise en œuvre de la méthode agile. Vous serez jugés sur la qualité de votre planification, l'adaptation des objectifs au fil des sprints, la régularité de vos réunions de sprint, la qualité de vos « daily » et la pertinence de votre découpage en tâches. Vous devrez consigner, au moins brièvement, tous ces éléments dans le projet Microsoft Planner.

L'analyse du projet sera évaluée à hauteur de 20% de la note finale. Vous serez jugés sur la pertinence de vos choix concernant :

  • cas d'utilisation
  • base de données
  • qualité de votre jeu d'essai
  • zoning, maquettes, prototypes
  • interface utilisateur

Vous serez évalués sur chacun des deux dépôts Git de votre application, conduisant à deux notes individuelles de réalisation. La mise en place des conteneurs capables de faire fonctionner l'application sera prise en compte. L'organisation du groupe de projet et la régularité du travail, retracées en partie dans la planification Microsoft Planner, seront également évaluées. L'ensemble de ces critères représentera 40% de la note finale.

Information

Pour vous évaluer, nous devons cloner votre dépôt GitLab, installer les dépendances, créer la base de données, charger les « fixtures » puis lancer les tests et démarrer le serveur Web. Veillez donc à ce que votre dépôt soit accessible et que les instructions pour installer et lancer votre application soient claires et précises. De plus, nous devons savoir ce que propose votre application. Ainsi, sans un minimum d'instructions sur les fonctionnalités présentes, sur les identifiants de connexion, sur les jeux de données disponibles et les procédures à réaliser, nous ne pourrons pas évaluer votre travail. Toutes ces informations doivent figurer clairement dans le fichier « README.md ».

Testez la mise en route de votre application : clonez votre dépôt dans un répertoire vide, installez les dépendances, créez la base de données, chargez les « fixtures » puis lancez les tests et démarrez le serveur Web. Si tout fonctionne, vous avez de grandes chances d'être évalué dans de bonnes conditions.

Le rapport en français que vous remettrez sera évalué à hauteur de 20% de la note finale.

Vous terminerez votre SAÉ par une soutenance en anglais qui constituera les 20% restants de la note.