Différences

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

--- projet:2020:aut:rapport [2020/08/31 16:38]
remy supprimée
+++ — (Version actuelle)
@@ Ligne 1: / Ligne 1: @@
-==== Date de rendu ====
-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, **Date a venir**
-==== Consignes pour le rapport écrit ====
-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 :
-  * 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 enseignantes), 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
-* Pensez à inclure les informations sur votre projet sur la page de garde (noms, 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 ====
-Les consignes peuvent être adaptées pour certaines équipes. Sauf mention contraire :
-  * Le rendu doit être un projet forge.univ-lyon1.fr, github ou équivalent. Vous donnerez l'URL dans la colonne correspondante de TOMUSS.
-  * Le code doit inclure au minimum un README.txt (ou mieux : un README.md qui permet de faire de la mise en forme, avec un joli rendu sur la forge) à la github avec des explications
-    * 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.
-    * Organisation et explications du code, explication de ce que font chaque exécutable/parties des données : comment les récupérer, 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 ====
-=== Consignes ===
-La soutenance reprendra rapidement les éléments du rapport (ci-dessus),
-et présentera la réalisation en s'appuyant au maximum sur des
-démonstrations concrètes. Vous utiliserez un video-projecteur (prenez
-votre machine pour projeter, et pensez à faire des tests avant pour vérifier
-que votre machine se branche correctement sur le vidéoprojecteur de la salle),
-et ferez en sorte que chaque membre de l'équipe s'exprime pendant la soutenance.
-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.