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é

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

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.

Les consignes peuvent être adaptées pour certaines équipes. Sauf mention contraire :

• Le rendu doit être un projet git sur 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 est composée de 3 parties: * Une présentation avec des slides comme support, 12 minutes environs * Une démonstration de votre projet, 5 minutes environs * Une séance de questions réponses, 5 minutes environs. * 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.

Sans entrer dans des détails, voici les points essentiels garder à l'esprit: * La présentation doit être comprise par le membre du jury qui n'a pas suivi le projet. Soyez pédagogue ! C'est surtout lui que vous devez convaincre que votre projet est intéressant. * N'oubliez pas/Ne négligez pas l'introduction de votre sujet: contraintes, objectifs, etc. * 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