.. _part3: ************************************************************************************************* 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 ============================= .. list-table:: :header-rows: 1 :widths: 60 15 * - É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** .. list-table:: :header-rows: 1 :widths: 28 18 18 18 18 * - 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 :doc:`chapitre 3 <../part1/chap3>` (objectif, spécifications, contraintes, livrables, chronogramme/Gantt, signature ; éventuellement maquettes et budget). **Grille d'évaluation du CDC** .. list-table:: :header-rows: 1 :widths: 28 18 18 18 18 * - 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 :doc:`chapitre 3 <../part1/chap3>`) : 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. .. admonition:: Rappel :class: important 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** .. list-table:: :header-rows: 1 :widths: 28 18 18 18 18 * - 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** .. list-table:: :header-rows: 1 :widths: 28 18 18 18 18 * - 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 ============================ 1. **Commencez tôt** et travaillez régulièrement, en équipe. 2. Gardez le **client** (l'enseignant) dans la boucle aux moments prévus par votre méthode. 3. **Documentez au fur et à mesure** : n'attendez pas la fin. 4. Tout sur **GitHub** (branches, PR, revues, issues) ; commits réguliers. 5. **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.