SAÉ 4.Real.01 - Développement d’une application complexe

Apprentissages critiques ¶

Vérifier et valider la qualité de l’application par les tests
Utiliser des techniques algorithmiques adaptées pour des problèmes complexes (par ex. recherche opérationnelle, méthodes arborescentes, optimisation globale, intelligence artificielle...)
Comprendre les enjeux et moyens de sécurisation des données et du code
Évaluer l’impact environnemental et sociétal des solutions proposées
Sécuriser les services et données d’un système
Optimiser les modèles de données de l’entreprise
Assurer la sécurité des données (intégrité et confidentialité)
Formaliser les besoins du client et de l’utilisateur
Identifier les critères de faisabilité d’un projet informatique
Définir et mettre en œuvre une démarche de suivi de projet
Appliquer une démarche pour intégrer une équipe informatique au sein d’une organisation
Mobiliser les compétences interpersonnelles pour travailler dans une équipe informatique
Rendre compte de son activité professionnelle

Introduction ¶

Cette SAÉ demande, à la suite de la SAÉ3.01, de faire évoluer une application existante, en l'améliorant et en ajoutant des fonctionnalités.

Lors du semestre précédent, vous avez réalisé une application Web conforme au cahier des charges et à tous les documents d'analyse que vous avez produits. Nous avons retenu un de vos projets pour chacun des sujets proposés. Vous vous appuierez sur le dépôt GitLab fourni pour commencer votre travail. Les améliorations porteront sur l'ergonomie, l'expérience utilisateur (UX), la qualité logicielle, la sécurité, l'expérience développeur (DX), les tests et la testabilité. Les nouvelles fonctionnalités seront à définir en fonction des besoins que vous aurez identifiés et selon des consignes précises que nous vous fournirons dans le wiki de chaque dépôt.

Le volume de travail par étudiant est fixé à 50 heures en dehors des séances de TP / TD, soit en moyenne 5h30 par semaine et par membre du projet.

Versionnage du projet ¶

Vous travaillerez avec une nouvelle équipe qui peut toutefois être identique à celle de la SAÉ3.01. L'un des membres aura la charge de « forker » le dépôt GitLab correspondant au sujet choisi. La collaboration entre les membres du groupe suivra les mêmes règles que celles présentées dans le TP « Collaboration avec Gitlab » :

Accédez à la liste des dépôts GitLab des projets, choisissez celui correspondant à votre sujet et effectuez un « fork »
Le 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

Remarque importante

Pensez à rebaser régulièrement votre branche de travail sur la branche principale pour éviter les conflits de fusion, en particulier avant de soumettre une « merge request ».
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. Inutile de faire la course au nombre de commits : la qualité prime sur la quantité.
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 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 un commit sur une partie des fichiers modifiés. Utilisez cette fonctionnalité pour structurer vos commits.
En cas d'erreur dans le dernier commit, utilisez l'option « amend » pour le corriger plutôt que d'en créer un nouveau.
Chaque message de commit sera clair, explicite et rédigé en anglais
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 ¶

L'application va évoluer et vous devez définir les étapes de cette évolution. Vous identifierez les points à améliorer, les fonctionnalités à ajouter, les technologies à utiliser et vous organiserez votre travail en conséquence.

Méthode de travail : agile ¶

Vous mettrez en pratique la méthode agile pour la gestion de votre projet. Vous effectuerez la planification dans GitLab avec le tableau des tickets (« issue boards » en anglais). Vous devrez définir diverses étiquettes (« labels » en anglais) dans GitLab. Les tickets étant désactivés sur le dépôt GitLab source, ils le seront également sur le dépôt « forké ». Il convient alors de les activer : activer les tickets GitLab

Voici une suggestion forte pour l'organisation du projet :

Un sprint par semaine
Une réunion 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 = tableau des tickets :
- « Backlog » = ticket ouvert dans le tableau des tickets
- À faire
- En cours
- « Merge request »
- Revue de code en cours
- Fait = ticket fermé dans le tableau des tickets
Priorisation des tickets (« issue ») selon plusieurs niveaux :
- Très urgent
- Urgent
- Urgence modérée
- …

Afin de leur permettre de suivre votre avancement, vous ajouterez les intervenants de TP concernés par le dépôt GitLab dès le début du projet.

Réflexions préliminaires ¶

L'application réalisée par vos collègues lors de la SAÉ3.01 présente des points à améliorer ou à finaliser. Dans tous les cas, la nouvelle version que vous allez proposer nécessite, après sa mise en place, une exploration de la documentation, des fonctionnalités, de l'interface utilisateur, des fixtures et des tests. Vous identifierez les points faibles et les points forts de l'application existante. Vous proposerez des améliorations et des évolutions sous forme de tickets (« issue ») dans GitLab.

Mesures correctives ¶

Vous vous appuierez sur les réflexions préliminaires pour définir les mesures correctives que vous apporterez à l'application.

Ajout de fonctionnalités ¶

Vous prendrez connaissance des consignes spécifiques à chaque dépôt GitLab pour définir les fonctionnalités supplémentaires que vous devez implémenter. Vous ajouterez ces fonctionnalités sous forme de tickets (« issue ») dans GitLab et vous les prioriserez avec les étiquettes correspondantes. Vérifiez la cohérence entre les fonctionnalités que vous proposez et les mesures correctives que vous avez identifiées.

Tests automatisés ¶

Vous devrez compléter les tests existants et couvrir les nouvelles fonctionnalités par des tests automatisés. Vous vous appuierez sur la ressource « R4.02 | Qualité de développement » pour définir une stratégie de tests adaptée à votre application.

Application sous forme de conteneurs ¶

L'application finale sera déployée sous forme d'un conteneur Docker.

Vous vous appuierez principalement sur les ressources « R4.08 Crypto et sécurité » et « R4.Real.08 | Virtualisation ».

Les divers services seront portés par une pile de conteneurs
La procédure de démarrage du service sera documentée

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

Vous présenterez votre réalisation en anglais selon des modalités à venir.

Déroulement, suivi et évaluation ¶

Le précédent découpage constitue la liste des livrables. Vous pourrez réaliser plusieurs étapes en parallèle. Les intervenants de certaines ressources seront vos référents et une partie d'entre eux vous évaluera.

Déroulement ¶

Puisque vous êtes en cours d'acquisition d'une partie des connaissances et compétences que vous devez mettre en œuvre, le début de la SAÉ sera axé sur la réflexion, en tirant les enseignements des méthodes de gestion de projet utilisées et des résultats obtenus lors de la SAÉ3.01. Vous vous projetterez vers la nouvelle réalisation en faisant des choix judicieux.

Vous pourrez ensuite appliquer les mesures correctives faisant appel aux technologies que vous maîtrisez déjà et commencer la création des nouvelles fonctionnalités demandées. Une fois que vos connaissances en API Platform seront plus fournies, vous pourrez mettre en place et sécuriser l'API et compléter les fonctionnalités qui s'appuient dessus.

La mise en place de conteneurs pour héberger l'application pourra intervenir dans les dernières semaines, en même temps que la finalisation des fonctionnalités et la construction de la présentation au client en anglais.

La dernière semaine avant le départ en stage (semaine 14) est presque exclusivement réservée à la SAÉ. Ce sera l'occasion de finaliser votre travail et répéter votre présentation en anglais.

La présentation orale au lieu la dernière semaine.

Suivi ¶

Les intervenants les plus aptes à vous conseiller sont ceux qui vous suivent dans les ressources associées et que vous voyez régulièrement en TP / TD. Vous pourrez donc effectuer un voire deux points hebdomadaires avec votre intervenant de :

« R4.01 | Architecture logicielle » et « R4.02 | Qualité de développement » pour la partie Symfony et API Platform
« R4.Real.10 | Complément web » pour la partie Ajax
« R4.08 Crypto et sécurité » et « R4.Real.08 | Virtualisation » pour la partie Docker
« R4.05 | Anglais » et « R4.06 | Communication interne » pour la présentation orale en anglais aux clients / collègues

Vous ajouterez vos intervenants d'informatique dans le dépôt GitLab de votre projet.

Les conseils concernant la SAÉ que vous pourrez 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. Les séances de TP / TD des ressources associées à la SAÉ ne sont pas le moment de travailler sur la SAÉ, simplement l'occasion de faire un point d'avancement avec votre intervenant.

É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.

Vous serez évalués sur le dépôt GitLab et la gestion de projet par votre intervenant de « R4.01 | Architecture logicielle » et « R4.02 | Qualité de développement ».

Remarque importante

La SAÉ permet d'évaluer vos compétences individuelles appliquées aux diverses technologies déployées. Les notes individuelles seront proportionnelles à la contribution de chaque membre du groupe de projet. Par conséquent, vous devez participer équitablement aux divers aspects du développement. Si vous n'effectuez que des contributions à faible technicité ou faible valeur ajoutée, votre note sera considérablement réduite.

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 gestion et les états successifs des tickets MGitLab, seront également évaluées.

L'ensemble des critères représentera 70% 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.

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