Sujets de mini-projets

Un seul sujet :

Voici le sujet.

But du projet

Un des buts du projet est de vous apprendre à travailler en groupe. Chaque groupe de projet devra comporter un chef de projet qui coordonnera le travail du groupe, veillera à la bonne marche du développement et sera le correspondant de l'enseignant en cas d'échanges de messages (en cas de problème grave dans le groupe, ou pour demander des informations complémentaires). Il gérera les conflits éventuels à l'intérieur du groupe. Il devra utiliser une adresse email de l'université correctement configurée pour comporter son nom (renseignez-vous comment faire) et ne pas changer d'email pour correspondre avec le correcteur.

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 !).

Constitution des groupes de projet

Chaque groupe de projet doit comporter 6 membres. Si le nombre total d'étudiants n'est pas divisible par 6 il sera accepté quelques groupes de 7 étudiants. La constitution des groupes devra être envoyée à grin@unice.fr avant le 4 mars minuit (0,5 point en moins par jour de retard), avec l'adresse du site Web du projet. Une des difficultés du projet est le nombre d'étudiants qui y participent. Il faudra bien vous organiser et bien répartir les tâches ; le chef de projet jouera un rôle important.

Toute question sur le projet devra être envoyée à grin@unice.fr par le chef de projet. Soyez précis et indiquez bien qui vous êtes (nom, prénom) et dans quelle filière vous travaillez (L3 info, L3 Miage ou autre) ; le sujet de l'email devra comporter [projet POO "Envoi des notes"] suivi du sujet particulier du message.

Site du projet

Chaque groupe devra écrire un site Web pour le projet.

Son adresse (cliquable) devra être envoyée par mail à grin@unice.fr au plus tard le 4 mars minuit (dans le message où vous donnerez la constitution du groupe). A cette date le site pourra ne comporter que le titre du projet et 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 (2 jours après la date limite pour rendre le 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). Il sera consulté régulièrement pour suivre l'avancement du projet.

Format obligatoire pour rendre le mini-projet :

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) :

IMPORTANT :

IMPORTANT : comment rendre le projet

Le projet devra être rendu le 22 avril minuit au plus tard (1 point en moins par jour de retard). Aucun projet ne sera accepté avec plus de 2 jours de retard.

Pour rendre le projet, envoyez un message électronique à grin@unice.fr. Un seul message par projet.

Le sujet du message sera du type "Projet L3 POO de toto, riri, titi, bobo, baba et tutu"

Le corps du message devra

  • donner les noms des étudiants du groupe ;
  • donner le nom du chef de projet ;
  • comporter en plus l'adresse (cliquable s'il vous plait !) de la page du projet sur le Web.
  • Le fichier zip (pas un autre format de compression, svp) 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 2 jours après la date limite pour rendre le projet, mais seul le fichier zip envoyé par mail sera utilisé par le correcteur. Si le fichier zip du projet fait plus de 10 Mo (arrangez-vous pour ne pas atteindre cette limite, en particulier utilisez des images de faible poids), il ne pourra être envoyé par email ; en ce cas seulement, envoyez un email qui indique l'adresse où le correcteur pourra récupérer le fichier zip (et laissez-le à cette adresse au minimum 15 jours).

    É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, en particulier si l'application utilise des images ou des petites icônes. 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.

    Notation

    Il sera tenu le plus grand compte de

    1. Bonne architecture de l'application (relations d'héritage et de composition en particulier).
    2. La lisibilité du code.
    3. L'extensibilité du code.
    4. L'ergonomie (faites tester par une personne étrangère au développement...). L'utilisateur ne doit pas avoir besoin d'aller lire le manuel de l'utilisateur que de façon exceptionnelle.
    5. La bonne documentation de l'application (documentation en ligne pour aider l'utilisateur mais aussi le guide de l'utilisateur et la documentation pour le développeur).
    6. Plus généralement la conformité du projet au format demandé.

    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.

    Mettez-vous à la place du correcteur et facilitez-lui la tâche. Il saura vous en tenir gré. ;-)

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

    Le correcteur n'essaiera pas de faire fonctionner une application qui ne démarre pas en lançant le fichier execute. Le projet n'aura donc aucun point sur tout ce qui concerne l'exécution. A ce niveau vous devez être capables de faire fonctionner un fichier jar.

    Les remarques, questions, signalements de fautes de frappes ou d'erreurs concernant ce sujet de projet peuvent être adressées à grin@unice.fr.

    Bon travail...