Projet 2026 - éléments d'administration

Contenu

1. Échéancier
2. Barème
3. Gestion des équipes (inscriptions, changements, etc.)
4. Composition des équipes (responsable, membres, salle, etc.)
5. Travailler en groupe

Échéancier

Pour que vous puissiez jugez de votre état d'avancement dans la réalisation du projet, et savoir ce qui vous attend pour la suite, vous trouverez ci-après un échéancier, rappelant la date des événements importants (inscription, rendu, ...), et indiquant en regard de chaque semaine les tâches que vous devriez normalement avoir terminées et les descriptifs plus précis de celles-ci.

Naturellement, c'est à vous de gérer le temps que vous consacrez à la réalisation du projet. Pour éviter une surcharge de travail en fin de semestre, tâchez cependant de respecter au mieux cet échéancier, et évitez surtout d'accumuler du retard.

Pour vous aider à vous organiser, chaque exercice du projet possède (voir le barème plus bas) un niveau de difficulté de 1 à 3 (comme pour les séries), suivi parfois du signe * indiquant que l'exercice est nécessaire pour la suite. Cela ne veut pas dire que les exercices sans * sont optionnels (tous les exercices comptent !), mais simplement que si vous ne faites pas un «exercice *» vous risquez d'avoir des problèmes pour continuer le projet. Fondamentalement, tous les exercices de P1 à P8, sauf P2, sont «*» et tous les exercices de P9 à P12 (et P2) ne sont pas bloquants pour la suite et vous permettent de vous organiser plus librement.

Par exemple un exercice indiqué [2*] est un exercice niveau 2 qu'il est conseillé de faire avant de passer à la suite.
Note : il n'y a aucun exercice [3*].

Barème

Le projet se fait par groupes de deux. Chaque groupe ne rend qu'une «copie», et les deux étudiant(e)s reçoivent, sauf cas exceptionnels, la même note.

Le projet est noté sur 36 points en tout répartis comme indiqué ci-dessous. Pour chacun des aspects codage (c.-à-d. tout sauf les premiers 6 points ci-dessous), les points correspondants seront répartis en environ 2/3 pour le codage lui-même (1/3 pour la compilation, 1/3 pour l'exécution correcte), 1/6 pour la conception et 1/6 pour le style et les commentaires.
Un malus de 0.1 sur la fraction pourra être appliqué en cas de mauvaise programmation manifeste (p. ex. variables globales abusives, new sans delete, pas de POO, etc.).

Il est impératif que le projet compile et s'exécute correctement sur les VMs de l'Ecole (VM IC-CO-IN-SC), seules machines officielles de ce cours.

Un projet sans polymorphisme ne pourra pas avoir plus que 0.65 (c.-à-d. pas plus que 24 points, ce qui correspond à une note maximale de 4.5).

Un malus de 0.2 sur la fraction pourra être appliqué en cas de non contact avec son assistant responsable.

Je rappelle également que la note fractionnaire obtenue sur le projet

• est combinée coefficient 3 avec l'ensemble des autres résultats du cours pour fournir la note finale ;
• ne peut en aucun cas être supérieure à 1.5 fois la note fractionnaire obtenue sur le reste du cours (revoir les explications fournies dans le premier cours).

Grille des points

Administration des équipes

Inscription

Si vous n'êtes pas dans la liste ci-dessous, inscrivez votre équipe (binôme) au moyen du formulaire ci dessous.

PENSEZ A VOUS INSCRIRE : vous n'avez que jusqu'au 13 mars pour le faire ! Après c'est moi qui décide...

Changements

Composition des équipes

Pour trouver votre équipe, cherchez votre nom à l'aide du navigateur (Ctrl+f)

[Attention ! La validation des inscriptions étant manuelle, votre nom n'apparaîtra dans cette liste qu'un certain temps après l'inscription.]

Travailler en groupe

L'architecture en place (machines virtuelles) limite malheureument fortement les moyens de collaborer facilement sur un même répertoire (pas de partage de fichiers). Il vous faudra donc malheusement procéder par échange/copie de fichiers comme indiqué par exemple dans le le wiki des utilisateurs des salles CO.

Pour votre organisation, je propose que l'un d'entre vous garde de façon séparée de son propre répertoire de travail, une version d'archive «officielle» et à jour. En clair, un des deux aura (au moins) deux répertoires : un de travail personnel et un d'archive du groupe. L'autre membre du binôme n'aura que son répertoire de travail personnel. Les échanges se faisant par copie entre ces différents répertoires (attention de ne pas écraser la version qui fonctionne, laquelle est conservée dans le répertertoire d'archive «officielle»).

Le point important (concept de base) de cette organisation est de séparer clairement endroit de travail et endroit de référence/d'archivage.

Peut être pour compléter, au niveau méthodologie :
si vous vous êtes bien réparti le travail (et avez bien compris le cours sur la compilation séparée) :

1. vous commencez par écrire le .h (du module dont vous êtes responsable) ;
2. une fois ceci fait, vous le proposez à votre binôme ; vous le discutez ensemble et soit vous êtes d'accord et passez au point 3 ; soit vous retournez au point 1 ;
3. vous écrivez un .cc correspondant, mais « vide » : chaque méthode ne fait rien ou juste un cout ou retourne un truc bidon, tout simple ;
4. vous donnez le .h et le .cc à votre binôme qui peut du coup travailler sur sa partie indépendamment (et aura d'ailleurs déjà commencé à le faire ; au point 1 pour sa partie ) et surtout compiler avec la vôtre ;
5. vous écrivez, de votre coté, le vrai .cc correspondant, méthode par méthode et vous le testez (je conseille d'écrire un test-MACHIN.cc avec MACHIN le nom de la classe sur laquelle vous travaillez) ;
6. quand vous êtes convaincu(e) que c'est tout bon vous donnez le .cc (et le test-MACHIN.cc) à votre binôme.

Je conseille aussi d'avoir (au moins) deux répertoires séparés :

• un « brouillon » : celui où vous travaillez « quotidiennement », essayez etc.
• un « propre » : dernière version à jour du projet, avec vos codes finis et les codes finis de votre binôme.

Lorsque vous copiez des choses de votre « brouillon » au propre et les codes « propres » reçus de votre binôme, je conseille de le faire à deux sur la même machine et regarder que tout va bien (compilation, exécution, bons résultats).

Je conseille même de faire des copies pour archive des « propres » à des étapes importantes (et ne plus y toucher). Cela permet d'éviter les catastrophes (surtout en fin de semestre (« Mais Monsieur la semaine passée tout marchait bien et j'ai juste changé un truc et là j'ai plus une version qui marche »)).