Projets LI : conseils

Les sujets de projet sont sortis, et je ne saurais trop recommander aux candidats de jeter encore une fois un coup d'oeil aux consignes que nous avons mises en ligne.
Je voudrais ajouter ici quelques conseils, inspirés par notre expérience des années précédentes.

• une étape importante du projet est la spécification de l'architecture du projet: peut-on découper le travail en modules, et quelles sont les relations entre ces modules ? Ce travail doit se faire avant la programmation et aboutit généralement à une représentation sous forme de diagramme (genre flow chart ou data flow diagram).
• une autre étape importante, de plus en plus, consiste à rechercher des outils, sous forme de modules ou de bibliothèques (libraries) qui peuvent contribuer à la réalisation de votre application. 
• pour ce travail, vous pouvez partir de la page ressources qui se trouve sur le site li, bien incomplète, mais qui a le mérite d'exister. 
• parmi les questions qu'il faut se poser dès le début (surtout pour les projets de M1), il y a la question de l'évaluation: comment allez-vous mesurer la qualité de votre programme ? Quelle métrique allez-vous utiliser ? 
• n'oubliez pas que le programme doit tourner le jour de la soutenance: il faut pratiquer autant que possible une programmation incrémentale, avec une version simple et sûre, que vous rendez plus sophistiquée progressivement, de sorte qu'à chaque instant vous avez une version qui tourne.  

à propos de la pré-soutenance:

• il faut préparer un exposé structuré, avec quelques transparents, et il est indispensable de faire des essais chronométrés pour garantir que vous respectez le temps imparti (en gros, 5 minutes par orateur). 
• si vous êtes particulièrement efficace, vous pouvez espérer faire 2 transparents à la minute, mais le plus souvent, surtout s'ils sont un peu denses, vous ne pourrez pas mettre moins d'une minute par transparent. Conclusion: 5 slides max par personne !

à propos du rapport:

• même s'il est rédigé à destination des encadrants, qui connaissent évidemment le sujet, il faut faire l'effort de décrire le projet, "avec vos mots", d'une manière compréhensible pour un lecteur qui ne connaitrait pas le projet. En particulier, il faut prendre le temps de décrire précisément :
• l'objectif du projet
• les techniques mises en oeuvre, qui en général sont données explicitement par l'encadrant ou proviennent d'articles (il faut donc citer les sources)
• l'implémentation de ces techniques
• veillez à citer les références sous la forme d'une bibliographie scientifique
• l'organisation du rapport n'a aucune raison de suivre l'architecture de votre programme
• les erreurs qui vous ont fait perdre le temps ne sont pas nécessairement les plus intéressantes à présenter, aussi bien dans le rapport que pendant l'exposé

à propos du code rendu:

• il faut indiquer clairement, par exemple dans un README, la ligne de commande permettant de faire tourner le programme, éventuellement la ligne de commande donnant accès à l'aide en ligne ; 
• en particulier pour les projets java: les enseignants ne testent pas dans Eclipse ou autre IDE: il faut un jar et la ligne de commande