- Accueil
- Programmation Web S5
- Apprentissages critiques
- Introduction
- Versionnage du projet
- Découpage du projet
- Déroulement, suivi et évaluation
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 des technologies et des 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 le dépôt GitLab
qui sera nommé « sae5-01
». Dans le dépôt, 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
- L'équilibre entre les contributions des membres du groupe sera considéré Remarque importante
La note de chacun des partenaires sera proportionnelle à la quantité et la qualité de ses contributions.
- Chaque
commit
sera le plus ciblé possibleRemarque importanteTout
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 des classes fournies, 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 uncommit
sur une partie des fichiers modifiés. Utilisez cette fonctionnalité pour structurer voscommits
. - Chaque message de
commit
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
- Proposition de découpage des états du Kanban :
- « Backlog »
- À faire
- En cours
- « Merge request »
- Revue de code en cours
- Fait
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 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 mettre en place une application de gestion des enseignements des enseignants et vacataires professionnels. Ceci consiste, chaque fin d'année universitaire, à choisir les enseignements auxquels chaque enseignant ou vacataire souhaite participer l'année suivante. Ce choix est fait sur la base d'une liste de matières pour lesquelles un certain nombre d'heures de CM, TD, TDM et TP sont à encadrer au fil des semaines (la maquette pédagogique) pour un nombre de groupes déterminé.
L'enseignant ou le vacataire professionnel choisit le nombre de groupes qu'il souhaite encadrer dans chacune des matières qui l'intéressent. Lors du choix, la présentation tient compte du calendrier global de chaque semestre avec les périodes de cours, de vacances, de stage, de SAÉ et d'alternance. Chaque personne complétant son choix doit pouvoir le modifier jusqu'à la date limite fixée par le département informatique. Une fois cette date passée, le département informatique doit pouvoir consulter les choix de chaque enseignant et vacataire pour chaque semestre. Lors de la saisie de ses vœux, l'enseignant ou le vacataire professionnel doit pouvoir visualiser dynamiquement sa charge hebdomadaire d'enseignement sur l'ensemble de l'année.
Le département informatique souhaite conserver l'historique des choix des enseignants et vacataires au fil des années pour pouvoir les consulter. Il souhaite également pouvoir consulter les choix des enseignants et vacataires pour un semestre donné. L'enseignant ou le vacataire professionnel doit pouvoir consulter les choix qu'il a déjà effectués les années précédentes.
La direction du département informatique souhaite visualiser facilement la liste des enseignants et vacataires professionnels qui ont choisi chacune des matières ainsi que le nombre de groupes pourvu et restant à pourvoir. Cette dernière information doit également être accessible à l'enseignant ou au vacataire professionnel lors de la saisie de ses vœux.
L'étape finale des vœux consiste en l'affectation des groupes de chaque matière aux enseignants et vacataires professionnels. Elle est réalisée par le département informatique en fonction des choix des enseignants et vacataires professionnels, mais aussi en fonction du nombre de groupes à encadrer. L'affectation doit être réalisée pour que chaque enseignant ou vacataire professionnel ait un nombre d'heures d'enseignement défini sur l'ensemble de l'année. L'affectation doit permettre à chaque groupe d'étudiants d'avoir un intervenant pour chaque matière, peu importe le nombre de candidats ayant fait le vœu d'intervenir dans ladite matière. Cette affectation est manuelle, doit être réalisée dans l'application et ne doit pas effacer les choix des enseignants et vacataires professionnels.
Le calendrier est initialisé par semestre et retrace les périodes de cours, de vacances, de stage, de SAÉ et d'alternance. La maquette pédagogique est initialisée à partir d'un fichier Excel fourni par le département informatique.
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.
Aspects techniques ¶
Cette SAÉ vous 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 vous seront imposées pour certaines parties de la SAÉ afin de vous évaluer sur l'ensemble des compétences à acquérir ce semestre.
API Web / back-office ¶
L'API Web 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 »
- Votre API Web sera basée sur
Symfony
etAPI Platform
et respectera les bonnes pratiques - Vous utiliserez une base de données
PosgreSQL
- Votre 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'API
- Une interface d'administration sommaire sera réalisée à l'aide de
EasyAdmin
- La gestion des utilisateurs et l'authentification seront réalisées sur
Symfony
- Des règles de sécurité limiteront l'accès aux données
- Les imports de fichiers seront réalisés en
Symfony
, soit par envoi de fichier, soit en ligne de commande avec la console - L'initialisation de la base de données sera réalisée en
Symfony
, soit par envoi de fichier, soit en ligne de commande avec la console - L'affectation des groupes aux enseignants et vacataires professionnels sera réalisée en
Symfony
Interface utilisateur ¶
L'interface utilisateur exploitera 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 ».
- Votre interface utilisateur sera basée sur
React
et respectera les bonnes pratiques - 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
- La navigation se fera à l'aide d'un système de routage
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
Application Symfony
/ API Platform
/ React
grâce à Symfony UX
¶
Pour faciliter la coopération Symfony
/ API Platform
/ React
imposée dans le sujet, vous utiliserez Symfony UX React
. Les bases de l'intégration des problématiques « front » dans un projet Symfony
avec Webpack Encore
sont posées dans la ressource « R5.15-R.516-R5.17 | Symfony avancé / Intégration continue ». Une preuve de concept est disponible sous forme d'un dépôt GitLab
.
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_sae501Vous 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.
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
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. Jean-Michel Nourrit 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 fichiers fournis et de 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 au 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 référents techniques, respectivement pour les aspects front et back. Vous pourrez solliciter les autres intervenants pour des conseils ponctuels.
Vous ajouterez vos référents dans la planification Microsoft Planner
de votre projet dès le début du projet.
Les conseils concernant la SAÉ que vous pourriez solliciter durant les TP / TD ne doivent pas empiéter sur le programme de la séance. Veillez donc à préparer des questions formulées clairement.
É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.
L'analyse et de conception seront évaluées à 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 le dépôt Git
de votre application. 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
».
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.