projet:2018:pri:start [Cours de Fabien Rico]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Description de l'UE LIFProjet en L3 informatique ======


Ces projets on lieu en 3eme année de la licence informatique. La version présentée ici est celle de l'année universitaire 2017-2018 (printemps). 

Cette session, l'UE s'adresse aux étudiants de L3 informatique :
    * Vous devez travailler par trinôme et proposer un choix de 3 sujets pour lundi 29/01/2018. Pour cela, utilisez [[https://tomuss.univ-lyon1.fr/2017/Printemps/UE-INF3051L|tomuss]].
    * La liste des [[projet:sujets2018printemps|sujets 2018 printemps]]

===== Planning de l'UE  =====
=== Pour les étudiants de L3 informatique ===

Les séances de TP projets sont le jeudi matin et le vendredi après-midi. Normalement les salles sont relativement proche, il est donc possible de venir dans n'importe laquelle de celle qui sont réservée. Même si votre emploi du temps ADE vous attribue une salle particulière.

Voici un lien vers l'emploi du temps **mentionnant toutes les salles** est [[http://adelb.univ-lyon1.fr/direct/index.jsp?projectId=1&ShowPianoWeeks=true&Cas=fabien.rico&resources=34212,34213,34214,34218,34219,34220&days=0,1&displayConfName=_DirectPlanning&weeks=&from=edt|ici]]

Le planning de présence des enseignants est [[https://docs.google.com/spreadsheets/d/1ynl9jXD1vrOcK3Qt1d7bkB1QwBGk2vb68NHQ0BGQqqI/edit?usp=sharing|ici]]

** La présentation des projets se fera le lundi 22 janvier en C5 entre 9h30 et 11h30. PRESENCE OBLIGATOIRE **

===Cours/TP sur l'utilisation de Git===

La séance d'introduction à Git aura lieu le lundi 29 janvier 2018 matin :
  * Cours de 9h à 9h30 en C1
  * 9h45-11h15 : TP, la moitié des étudiants (cf. TOMUSS pour la répartition), salles Grignard A-B-C-D
  * 11h30-13h : TP, l'autre moitié des étudiants, salles Grignard A-B-C-D

Les supports de cours :
  * Transparents projetés en cours : {{ :projet:2018:pri:git-slides.pdf |}}
  * Séance machine à suivre pas à pas : {{ :projet:2018:pri:seance-machine-git.pdf |}}
  * Fichier utilisé pendant la séance machine : {{ :projet:2018:pri:sandbox.tar.gz |}}
  * Transparents Git avancé : {{ :projet:2018:pri:advanced-git-slides.pdf |}}

===Cours de préparation à la soutenance===
Avec M. Yannick Vacher
^ Date               ^ Horaire  ^ Groupe concerné    ^ Salle         ^
| Mardi 6/3/18       | 14h-16h  | A    | C2 Nautibus   |
| Mardi 6/3/18       | 16h15-18h15  | B    | C2 Nautibus   |
| Mardi 13/3/18       | 14h-16h  | C    | TD3 Nautibus   |
| Mardi 13/3/18       | 16h15-18h15  | D    | TD3 Nautibus   |
| Mardi 20/3/18       | 14h-16h  | E    | TD9 Nautibus   |
| Mardi 20/3/18       | 16h15-18h15  | F    | TD9 Nautibus   |
| Mardi 27/3/18       | 14h-16h  | A    | TD1 Nautibus   |
| Mardi 27/3/18       | 16h15-18h15  | B    | TD1 Nautibus   |
| Mardi 3/4/18       | 14h-16h  | C    | TD1 Nautibus   |
| Mardi 3/4/18       | 16h15-18h15  | D    | TD1 Nautibus   |
| Mardi 10/4/18       | 14h-16h  | E    | TD1 Nautibus   |
| Mardi 10/4/18       | 16h15-18h15  | F    | TD1 Nautibus   |


===== Évaluation : livrables et soutenance =====

Vous serez noté majoritairement (environ 2/3 de la note) sur le travail réalisé : suivi au fil du semestre et rendu final du code. Le reste de la note sera fonction de la qualité du rapport et de la soutenance.

==== Dates importantes ====

  * Le rapport et un lien vers le code sont à rendre sur TOMUSS pour le XX avril 2018, avant minuit.
  * Les soutenances auront lieu le XX avril  2018.
==== Consignes pour le rapport écrit ====

Ces consignes sont générales pour l'ensemble des projets LIFPROJET. Discutez avec votre encadrant pour affiner (ou éventuellement modifier) les consignes au cas par cas. Pour les encadrants : n'hésitez pas à donner des consignes plus précises ou différentes, mais soyez clairs sur ce qui est attendu.

Ce 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 (même si en pratique l'enseignant qui le corrigera en saura sans doute plus que ça).

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

==== 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 déposerez un fichier url.txt avec le lien vers la forge en question sur 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 !

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.