Partie 3 | Projet

Objectifs

À l’issue de cette partie, chaque étudiant.e sera capable de :

Appliquer une méthodologie de développement à un projet réel, en équipe
Produire les documents associés (cahier des charges, fiche technique)
Développer un logiciel fonctionnel et le documenter
Analyser et présenter, de façon critique, le déroulé du projet à la lumière de la méthodologie suivie

Le fil rouge : le préliminaire

Un TP préliminaire sert de fil rouge à tout le cours :

Un client veut un logiciel de vente de produits (cosmétique, fruits, menuiserie, art, films, musique, …) avec un système de recommandation pour les utilisateurs.

Consigne : développer le logiciel en documentant chaque étape (documenter vos choix, basés sur vos connaissances du moment). Livrables : un petit rapport (10 pages max) + une petite démo. Le préliminaire n’est pas noté (sauf s’il n’est pas rendu) : il alimente ensuite les exposés, le TP1, le TP2 et le projet.

Récapitulatif de l’évaluation

Élément (toujours en groupe)	Poids
Exposés (méthodologie assignée)	20 %
TP1 — Cahier des charges	20 %
TP2 — Fiche technique	20 %
Projet / Examen	40 %

1. Les exposés (20 %)

Chaque groupe présente en profondeur une méthodologie assignée par l’enseignant (Cascade, V, Itératif, Spirale, Agile/Scrum, Agile/Kanban) — typiquement un exposé par séance, sur ~2h.

Contenu attendu :

Une description de la méthode ;
Le plus important : utiliser l’exemple préliminaire comme base pour expliquer l’exécution pas-à-pas de la méthode ;
Les cas d’utilisation : avantages, limites, contextes d’application.

Grille d’évaluation des exposés

Critère	Insuffisant	Correct	Bien	Excellent
Compréhension de la méthode	Méthode mal comprise	Bases correctes	Bonne maîtrise	Maîtrise fine, nuancée
Application au préliminaire (pas-à-pas)	Absente ou hors sujet	Superficielle	Claire et correcte	Détaillée et convaincante
Avantages / limites / contextes	Non traités	Partiels	Corrects	Analyse critique pertinente
Qualité de la présentation (oral, support)	Confuse	Acceptable	Soignée	Professionnelle

2. TP1 — Cahier des charges (20 %)

En groupe, rédigez le cahier des charges du préliminaire, en suivant la structure vue au chapitre 3 (objectif, spécifications, contraintes, livrables, chronogramme/Gantt, signature ; éventuellement maquettes et budget).

Grille d’évaluation du CDC

Critère	Insuffisant	Correct	Bien	Excellent
Objectif & contexte	Flous	Présents	Clairs	Clairs et bien justifiés
Spécifications (fonct./non fonct.)	Lacunaires	Basiques	Complètes	Complètes et priorisées
Contraintes & livrables	Absents	Partiels	Corrects	Précis et exploitables
Chronogramme (Gantt)	Absent	Approximatif	Réaliste	Réaliste et détaillé

3. TP2 — Fiche technique (20 %)

En groupe, produisez la fiche technique du préliminaire (voir chapitre 3) : architecture générale (MVC, design patterns, API/REST), diagrammes UML (cas d’utilisation, classe, objet, séquence), choix logiciels, maquettes, gestion des données.

Rappel

La fiche technique doit permettre de réaliser le logiciel sans recontacter le client ni relire le cahier des charges.

Grille d’évaluation de la fiche technique

Critère	Insuffisant	Correct	Bien	Excellent
Architecture générale	Absente	Esquissée	Cohérente	Cohérente et justifiée
Diagrammes UML	Manquants	Incomplets	Complets	Complets et rigoureux
Choix techniques & maquettes	Absents	Partiels	Corrects	Complets et réalisables
Autosuffisance (réalisable sans le client)	Non	Partiellement	Largement	Totalement

4. Le projet (40 %)

Le projet se déroule en équipe, chaque groupe se voyant assigner une méthodologie (V, Itératif, Spirale, Agile/Scrum, …). L’objectif : développer une plateforme à la lumière de la méthode assignée.

Attendus :

Décrire chaque étape du développement ;
Analyser les forces et faiblesses de la méthodologie suivie ;
Présenter les cas d’utilisation (grand/moyen/petit projet : e-commerce, logiciel, mobile, …) ;
Présenter la solution ;
Analyser le résultat obtenu à la lumière des défis de la méthode utilisée.

Selon la méthodologie assignée, le suivi diffère. Par exemple en Agile/Scrum, l’enseignant joue le rôle du client et vous le rencontrez à la fin de chaque sprint.

Livrables :

Un rapport en anglais (~10 pages) ;
Le code ;
Un document de déploiement et d’exécution (README) ;
Une vidéo (5 min max : démonstration d’utilisation + « pub »).

Note

Variante hackathon (selon l’année). Certaines années, le projet prend la forme d’un hackathon : un seul projet pour toute la promo (ex. un logiciel de gestion complète d’une entité universitaire comme l’IFRI), où chaque groupe développe un module selon une méthodologie assignée, avec collaboration inter-groupes et tout le travail sur GitHub (branches main/dev/dev-moduleX, pull requests + revue + merge, et issues). L’évaluation combine alors une note globale et une note spécifique au module. L’enseignant indique en début d’année la formule retenue.

Grille d’évaluation du projet

Critère	Insuffisant	Correct	Bien	Excellent
Logiciel fonctionnel	Ne fonctionne pas	Fonctionne partiellement	Fonctionne bien	Fonctionne parfaitement, soigné
Application de la méthodologie	Non appliquée	Appliquée en surface	Bien appliquée	Appliquée et analysée finement
Documentation (rapport EN, README)	Absente	Minimale	Complète	Complète et professionnelle
Analyse critique (forces/faiblesses)	Absente	Superficielle	Pertinente	Approfondie et nuancée
Démonstration (vidéo)	Absente	Confuse	Claire	Claire et convaincante

Conseils et bonnes pratiques

Commencez tôt et travaillez régulièrement, en équipe.
Gardez le client (l’enseignant) dans la boucle aux moments prévus par votre méthode.
Documentez au fur et à mesure : n’attendez pas la fin.
Tout sur GitHub (branches, PR, revues, issues) ; commits réguliers.
Testez avant de livrer ; soignez le README et la vidéo.

Note

Les dates de rendu et la composition des groupes sont communiquées par l’enseignant en cours.