Voici le sujet au format pdf.
Vous trouverez ici la liste des groupes qui ont envoyé un mail avec un lien. Si vous voyez des erreurs, veuillez me contacter.
Il est nécessaire d'apprendre à travailler en groupe (4 étudiants par groupe pour ce projet). Les étudiants seuls devront en expliquer la raison avant de commencer à travailler sur le projet, sinon ils ne seront pas corrigés (avec une note en conséquence).
Un autre but important (sans doute le plus important) est de vous faire pratiquer les grands principes de programmation que vous avez appris : encapsulation (par exemple, pas de variables publiques, et le moins possible de variables protected), modularité, extensibilité (du polymorphisme en particulier plutôt que des "switch"), réutilisabilité, documentation de l'application (javadoc en particulier pour une application Java), etc.
Vos classes devront appartenir à des paquetages (obligatoire !).
Enfin un autre but est de vous montrer une utilisation de l'informatique dans un autre domaine scientifique.
Chaque binôme devra écrire un site Web pour le projet.
Son adresse (cliquable) devra être envoyée par mail à sverel -*-at-*- gmail . com au plus tard le 23 mars 2007 à midi. A cette date le site pourra ne comporter que les noms des participants. Vous y indiquerez ensuite (au moins) l'état d'avancement du projet (avec les dates des étapes) et les liens vers des sites que vous aurez utilisés pendant le développement. A la fin du projet, un lien pointera vers la page finale du projet (présentation du projet, exécutable,...).
Le contenu de ce site comptera dans la note finale (la forme est secondaire ; inutile de passer trop de temps dessus).
Tout d'abord un principe général important que vous devez toujours avoir en tête pendant votre travail sur ce projet :
Plus vous faciliterez la tâche du correcteur en écrivant une application avec une bonne ergonomie et ne nécessitant pas des recours constants au manuel d'utilisation, en expliquant vos choix et votre code, en lui évitant des manipulations facilement automatisables, plus vous serez sur la bonne voie ; plus vous lui compliquerez la tâche en n'expliquant rien ou en fournissant une application difficile à utiliser et nécessitant des manipulations complexes et longues, moins vous pourrez espérer une note convenable. Ce principe général n'est pas seulement là pour faire gagner du temps au correcteur (quoique...) mais il est surtout là pour vous habituer à fournir des applications conviviales, faciles à utiliser et faciles à maintenir pour des évolutions futures.
Le projet devra être fourni sous forme d'un fichier zip (pas de tar.gz ou autres formats) contenant tout sur le projet (vous devez respecter les noms des fichiers donnés ci-dessous) :
Vous pouvez aussi (c'est optionnel) ajouter des diagramme UML (de classes ou autres) si vous savez les faire. Mettez-les dans le fichier zip et indiquez où ils se trouvent par un lien dans la page Web du projet.
IMPORTANT :
Le projet devra être rendu le vendredi 6 avril minuit au plus tard (tout dépassement aura un impact négatif sur la note).
Pour rendre le projet, envoyez un message électronique à sverel --a-t--- gmail . com. Un seul message par projet.
Le sujet du message sera du type "Projet licence info de toto, riri et titi"
Le corps du message devra
Le fichier zip attaché au message devra comporter tout votre travail sur ce projet (relisez le début de cette page). Ce fichier zip devra aussi être accessible et récupérable depuis la page Web du projet, mais seul le fichier zip envoyé par mail sera utilisé par le correcteur.rappeler les noms des étudiants du binôme comporter en plus l'adresse (cliquable s'il vous plait !) de la page du projet sur le Web.
Évitez d'envoyer plusieurs messages pour un même projet. Testez si tout va bien en vous envoyant d'abord le message et en vous plaçant dans un environnement neutre (par exemple pas sur la machine qui contient votre page Web et vos répertoires de développement) pour le tester. Un bon conseil : testez en utilisant le jar et pas les classes en dehors du jar. Chaque année un grand nombre de projets ne fonctionnent pas parce que les auteurs n'ont pas testé le fonctionnement avec le jar ; n'attendez donc pas le dernier moment pour construire le jar et le tester.
Seule la première version envoyée sera prise en compte pour la correction.
Il sera tenu le plus grand compte de
Une application qui fait le minimum mais qui le fait bien, d'une façon robuste, conviviale, extensible et bien documentée, est préférable à une application avec beaucoup de fonctionnalités mais qui se plante ou qui est difficile à utiliser et pas extensible. Un grand nombre de fonctionnalités supplémentaires ne pourra compenser un manque de documentation correcte ou un autre point important indiqué ci-dessus.
Toute application qui ne respectera pas le format indiqué ci-dessus ne sera pas corrigée (et évidemment la note sera en conséquence). Idem pour les applications qui ne seront pas documentées ou qui auront, par exemple, une javadoc sans information véritable. Il est temps de prendre des bonnes habitudes pour ceux qui ne les ont pas déjà (une toute petite minorité évidemment...).
Bon travail...