Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projet:livrables-soutenance [2021/01/14 17:26]
remy [Consignes pour la soutenance]
+++ projet:livrables-soutenance [2024/04/11 09:20] (Version actuelle)
remy [Rendu du code]
@@ Ligne 2: / Ligne 2: @@
 Le rendu se fait sur Tomuss, sous la forme d'un fichier pour le rapport et d'un lien vers un dépôt git pour le projet.
-/* **A rendre avant le 14 Janvier à 23h59**
+ **A rendre au plus tard le jour de votre soutenance**
-*/
+==== Consignes pour le rapport individuel ====
-==== Consignes pour le rapport écrit ====
+Chaque étudiant doit rendre un rapport individuel.
-Le rapport sera court : 4 à 8 pages maximum,  sauf si vous avez vraiment besoin de plus (le but n'est pas de faire du volume, c'est plutôt une bonne chose si vous êtes concis). Il devra couvrir les points suivants :
+Ce rapport est très court (2 pages de texte maximum, + image ou extrait de code si besoin).
+Il doit détailler un aspect du travail effectué personnellement par l'étudiant. Il peut s'agir du détail d'un aspect technique particulier (comment réussir à rendre un site web responsive, comment gérer l'animation d'un personnage 3D...), d'un aspect théorique (détail d'un algorithme ou d'une équation qu'il a fallut comprendre pour pouvoir résoudre une partie du projet, etc.), ou de tout autre point sur lequel vous avez été particulièrement impliqué et pour lequel vous êtes fier d'avoir résolu un problème non-trivial, ou d'avoir appris à utiliser un concept complexe, etc.
-  * Vue d'ensemble du travail réalisé /*(courte, attention à ne pas paraphraser le code) : le point de départ (et ses limitations => pourquoi votre problème est-il utile ?), la solution  que vous avez proposé, et ce qui vous permet de penser que cette solution est bonne. */
-/*
-  * Vue d'ensemble de l'architecture de votre projet : comment sont organisés les parties de votre projet, comment l'information circule-t-elle ? Des diagrammes type UML peuvent aider.
-*/
-  * Si applicable, description de l'organisation ou de la communauté à laquelle vous avez contribué (organisation, communication, flot et  outils de développements, prises de décisions, ...), et de la manière  dont vous avez interagi avec elle.
-  * Si applicable : difficultés, essais infructueux, résultats négatifs
-  * Bilan du projet : les bons et les mauvais points (de votre côté, et du  côté de l'équipe enseignante), les pistes d'améliorations.
-Le rapport s'adresse à un informaticien, mais pas forcément à quelqu'un de familier avec le logiciel sur lequel vous travaillez ni au contexte du projet.
-La documentation utilisateur ne fait pas partie du rapport. Si elle est nécessaire, elle sera directement ajoutée à la documentation de votre projet et sera jointe en annexe au rapport.
 === Conseils et erreurs à ne pas faire ===
-Bien sûr, les règles habituelles pour les documents écrits s'appliquent à ce rapport, sur le fond comme sur la forme. Voir par exemple cette page pour un ensemble de bonnes pratiques : https://ensiwiki.ensimag.fr/index.php?title=R%C3%A9daction_de_documents_%C3%A9crits
+Bien sûr, les règles habituelles pour les documents écrits s'appliquent à ce rapport, veillez à ce qu'il ait un niveau "professionnel" sur le fond comme sur la forme.
-* Pensez à inclure les informations sur votre projet sur la page de garde (noms, affiliation, date, encadrant, ...)
+* Pensez à inclure les informations sur votre projet sur la page de garde (nom, affiliation, date, encadrant, ...)
-* Attention à l'utilisation de contenu que vous n'avez pas écrit vous mêmes. Même pour des contenus libres (Wikipedia, ...), la licence vous oblige en général au minimum à citer vos sources. /* , et fixe souvent d'autres contraintes. Ne pas respecter la licence de ces contenus est illégal. En l'absence de licence, c'est le droit d'auteur qui s'applique et qui est encore plus restrictif. Vous avez toujours le droit de courte citation, mais celui-ci est très encadré par la loi : https://fr.wikipedia.org/wiki/Droit_de_courte_citation
-*/
 ==== Rendu du code ====
@@ Ligne 43: / Ligne 27: @@
     * Objectifs : ce que fait le projet
-    * Installation : comment le tester/compiler, dépendances. Assurez-vous à l'avance que votre projet sera compilable par votre évaluateur : autant que possible donner une procédure qui fonctionne sur les machines de l'université, ou bien vérifiez avec votre encadrant qu'il dispose de toutes les dépendances sur sa machine de travail.
+    * Installation : comment le tester/compiler, dépendances. Assurez-vous à l'avance que votre projet sera compilable par votre évaluateur.
-    * Organisation et explications du code, explication de ce que font chaque exécutable/parties des données : comment les récupérer, etc.
+    * Explication de l'organisation du code, pour pouvoir trouver le code correspondant à une partie du code spécifique (front-end/back-end, etc.)
-    * Résultats
-=> On peut lire directement sur la forge mais le fichier doit être précis. Ajoutez un README dans les sous-répertoires quand cela semble nécessaire.
 ==== Consignes pour la soutenance ====
@@ Ligne 57: / Ligne 37: @@
 La soutenance est composée de 3 parties:
-   * Une présentation avec des slides comme support, 12 minutes environs
+   * Une présentation avec des slides comme support, 12 minutes environ
-   * Une démonstration de votre projet, 5 minutes environs
+   * Une démonstration de votre projet, 5 minutes environ
-   * Une séance de questions réponses, 5 minutes environs.
+   * Une séance de questions réponses, 5 minutes environ.
    * Au total, la soutenance dure 25 minutes, avec le temps de branchement/débranchement
-Vous utiliserez un video-projecteur (prenez votre machine pour projeter), et ferez en sorte que chaque membre de l'équipe s'exprime pendant la soutenance.
+Vous utiliserez un video-projecteur:
+   * Prenez votre machine pour projeter (Si vous ne pouvez pas en avoir un, merci de nous prévenir)
+   * Vous ferez en sorte que chaque membre de l'équipe s'exprime pendant la soutenance.
+   * Merci d'arriver avec votre ordinateur allumé et prêt à projeter.
 === Conseils pour la présentation ===
@@ Ligne 71: / Ligne 54: @@
     * N'entrez pas dans des détails techniques (segments de codes...). La présentation doit être **plaisante et facile à suivre**
     * Présentez et justifiez vos choix techniques (bibliothèques, languages, algorithmes, framework, etc.), mais en restant compréhensible par un non-spécialiste.
-    * 1 slide par minute est un objectif raisonnable. Les slides ne doivent pas être surchargés
+    * 1 slide = 1 minute est un objectif raisonnable. Les slides ne doivent pas être surchargés
+    * Essayez de chiffrer le temps que vous avez passé sur les différentes tâches, par exemple avec un diagramme camembert. En effet, il est parfois difficile a un non-spécialiste de savoir si une tâche complexe a été faite un 3 lignes avec un appel à une librairie ou a demandé 2 mois de travail (exemple: algorithme de machine learning réutilisé tel quel ou recodé, animation de personnage pris dans une bibliothèque ou générée manuellement, etc.
-/*
+Toutes les soutenances sont ouvertes à toutes les équipes de LIFPROJET (et même à vos collègues qui n'ont pas suivi le module).
-La soutenance dure 12 minutes (vous pouvez aller jusqu'à 15 min si c'est vraiment nécessaire, mais ne dépassez pas), y compris les explications de code si nécessaire, suivie de 5 minutes de démonstration de votre logiciel, puis d'une
-séance de questions de 5 minutes (total : 25 min y compris le temps de brancher/débrancher son ordinateur). Faites impérativement une répétition (en vous mettant au plus proche des conditions réelles) pour mesurer le temps nécessaire à votre présentation.
-Toutes les soutenances sont ouvertes à toutes les équipes de LIFPROJET (et même à vos collègues qui n'ont pas suivi le module). Pour que les soutenances soient plus vivantes, on impose à chaque équipe d'être présente à au moins une soutenance autre que la sienne.
-=== Conseils et erreurs à ne pas faire ===
-Attention, la soutenance doit être compréhensible par tous les membres du jury, qui ne sont pas forcément spécialistes de votre domaine. Le but n'est pas forcément de tout raconter : n'hésitez pas à passer les détails techniques sous silence. Si vous avez beaucoup de contenu technique, il est déjà dans le rapport : fixez-vous comme objectif de donner envie de lire le rapport aux personnes qui vous écouteront. Il est souvent pertinent d'insister plus sur le problème que vous avez cherché à résoudre que sur la solution : vous pouvez envisager que votre public n'ai pas compris les détails de votre solution, mais s'il n'a pas compris le problème, c'est beaucoup plus grave !
-Pensez cependant à présenter les outils et solutions techniques que vous avez adoptés (langages, librairies, frameworks...) afin de mettre en évidence les compétences que vous avez acquises.
-Un ordre de grandeur pour dimensionner la présentation : 1 minute par transparent, c'est très dense (tenable uniquement si vos transparents sont très sobres et que votre discours est très bien préparé). 2 minutes par transparent vous permet une présentation plus posée et limite le risque de perdre l'auditoire. En cours, un enseignant passe souvent environ 3 minutes par transparent.
-Parmi les erreurs classiques à éviter :
-  * Vouloir trop en dire (transparents trop chargés, ou autre erreur de débutant : penser qu'on pourra faire une meilleure présentation en parlant très vite !). Si vous avez un sujet très mathématique, vous ne pourrez pas expliquer toutes les équations que vous avez utilisé, de même que si vous avez un sujet informaticien vous ne pourrez pas non plus montrer tout votre code (en fait, c'est rarement une bonne idée de montrer du code en soutenance).
-  * Les transparents ou les démonstrations de logiciels illisibles. Le vidéoprojecteur que vous allez utiliser n'est pas forcément aussi bon que votre écran => pas de petite police, pas de dessin clair sur fond clair ou foncé sur fond foncé !
-  * Oublier les informations de base : le titre, vos noms et affiliation sur le transparent de titre, numéro sur chaque transparent.
-  * Mal préparer la démo. La loi de Murphy fait que ce qui devait marcher ne marchera pas le jour J. Ne laissez rien au hasard : tout doit être prêt (pas de reboot, autant que possible une fenêtre déjà ouverte et prête à être utilisée sur votre ordinateur), tout ce que vous allez montrer doit avoir été testé. Autant que possible, prévoyez une vidéo et/ou des copies d'écran pour le cas où votre démonstration ne marcherait pas, ou bien faites l'ensemble de votre démo sur ces copies d'écran.
-  * Bien sûr, les lois sur le droit d'auteur et droit de citation (cf. partie rapport) s'appliquent également pour une présentation sur transparents.
+/*
 Quelques slides qui étaient présenté les autres années : {{ :projet:2020:aut:presentation_projet_l3.pptx |}}
 */