La date limite de rendu est le 21 Avril à minuit. 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.

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.

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

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

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.

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.

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.

Pour les étudiants en M1 CAPES, les consignes ci-dessus sont adaptées comme ceci :

* Soutenances le jeudi 11/4/2019, salle Nautibus TD1 en présence de Fabien Rico et Matthieu Moy, 9h30-11h30

* La durée de vos soutenance sera de 30 min par équipe (mise en place, présentations, démo et questions).

* La date limite de rendu du rapport est fixée au mardi 9/4/2019, 14h00, sur TOMUSS. Mêmes consignes que ci-dessus pour le rapport.

* Rendez les transparents présentés à la soutenance, de préférence au format PDF, sur TOMUSS avant le début de la première soutenance.

* Nous vous imposons d'être présents pendant les soutenances de toutes les équipes (d'une part parce que les soutenances devraient vous apprendre des choses si elles sont bien faites, et aussi pour vous donner l'occasion de faire votre présentation devant plus de 2 personnes).