Travaux pratiques
ou projet

Déroulement

Le projet ou les travaux pratiques ont pour but de vous familiariser avec les outils réseaux ou les mécanismes de communication vus en cours. L'organisation des travaux pratiques est la suivante :

• Séance de TP: étude du problème. Développement avec l'encadrant des grandes lignes de la solution. Réalisation de la maquette et premiers tests. Les grandes lignes des conclusions. Prises de notes.
• Travail après séance: Rédaction. Mise au propre et en page des travaux. Analyses complètes et explications des travaux réalisés. Utilisation de références et des notes bibliographiques. Argumentaire de la conclusion.

Les travaux peuvent s'effectuer par binôme. La rédaction d'un rapport final PERSONNEL et UNIQUE suivra la réalisation des TP. Ce rapport consignera les résultats, les analyses et les conclusions des diffèrents points abordés.

Evaluation de travaux

L'évaluation des travaux repose sur les éléments suivants :

1. un compte rendu rapport (sans précision donnée alors le format a utiliser est en pdf),
2. des fichiers sources (*.py, *.sh, etc.),
3. un jeu de test si un programme a été développé,
4. une démonstration éventuelle à la demande de l'encadrant.

Le compte-rendu vise à présenter les travaux réalisés et expliquer les résultats obtenus. Il doit présenter le problème et décrire la solution. Par contre, il ne doit pas être une simple copie du code ou du sujet. Ainsi, il doit souligner les points suivants:

• Mettre en évidence votre travail (technique utilisée pour résoudre un problème spécifique, justification des choix si plusieurs solutions sont possibles, limites de votre approche, etc.).
• Donner l'interface d'utilisation du code rendu (ligne de commande, les options etc.) sous la forme de la description de la syntaxe et éventuellement complétée par un ou des exemples.
• Lorsque, le TP consiste à compléter un fichier d'un code fourni, le compte-rendu doit indiquer les modifications apportées. Les portions de lignes ajoutées ou les lignes modifiées dans le code source sont à mettre dans le compte-rendu. Il convient de précéder les inclusions de code dans le rapport par une présentation ou une explication.
• De manière générale, le compte-rendu doit montrer votre démarche scientifique. Chaque action ou résultat doit être expliqué. Chaque explication doit être démontrée. Tout ce que vous avancez doit s'appuyer sur des faits réalisés ou observables (et donc justifiables).

Le rapport est un document compact qui doit être redigé. Son contenu doit être pertinent. Par exemple, les lignes de code fournies par l'enseignant n'ont pas leur place dans votre rapport. Par contre quelques lignes peuvent être reprises lorsqu'elles entoure votre production. Dans ce cas, elles servent à définir le contexte dans lequel se place vos lignes de code. La pertinence du contenu de la réponse est à juger par vous-même pour les différentes questions que vous avez à traiter. Enfin, votre rapport doit donner envie de le lire. Pour cela, il est important de soigner sa rédaction. Ces consignes doivent au MINIMUM être prises en compte :

• Suivre ces conseils de rédaction.
• Au niveau du style de document, utilisez ces ressources pour la réalisation du rapport. Ainsi, vous n'avez plus à vous préoccuper de la forme et vous pouvez vous concentrer sur le fond.
• A chaque question du sujet, vous devez reformuler la question avant de rédiger la réponse.
• Le compte-rendu doit être auto-descriptif (self-contained) et se présenter sous la forme d'un seul fichier.
• Si il y a des dessins et des graphismes, ceux-ci doivent être insérés avec le texte. Ils doivent avoir une légende et un être cités dans le texte.
• Les faits, les conclusions, les remarques, les analyses doivent comporter les éléments qui prouvent ou attestent ce qui est avancé
• Lorsque le rapport comporte des dessins ou des courbes, la partie rédactionnelle ne doit pas être plus faible que la place consacrée aux dessins. Le rapport ne doit pas devenir une "bande dessinée".

Sauf indication particulière donnée lors de la séance de TP, le format du compte-rendu doit suivre cette règle:

• Si le compte-rendu ne comporte aucun dessin et qu'il est a rendre en fin de TP, un fichier texte est suffisant. Attention: Dans le cas d'un fichier texte, utiliser un encodage en UTF-8 pour que les caractères accentués soient lisibles.
• Dans tous les autres cas (c'est à dire si le compte-rendu comporte des dessins ou qu'il est à rendre après la séance de TP, rédigez votre compte-rendu en Latex avec le modèle fourni (tgz) et rendre un fichier au format pdf.

Les fichiers sources doivent bien entendu être en rapport avec les codes présentés dans le compte-rendu. Ils ne doivent pas comporter de "bugs" à l'exécution. Enfin, ils doivent montrer la qualité du codage réalisé:

• organisation logique et découpage en fonctions/modules,
• algorithmique,
• prise en compte des erreurs,
• code additionnel utilisé lors du debug, etc.

Les codes sources doivent être LISIBLES et pour cela ils doivent :

• être compacts (éviter les copier-coller, privilégier les boucles et les procédures),
• être commentés,
• être indentés,
• comporter des noms de variables et de procédures "parlants".

Le jeu de test est souvent celui fourni par l'enseignant ou à défaut le votre. L'objectif consiste à rendre un kit prêt à exécuter à l'évaluateur.

La démonstration doit permettre de s'assurer :

• du respect du cahier des charges (fonctionnalités mises en oeuvre et l'absence d'erreurs),
• de la robustesse du code,
• de la maîtrise du sujet et des outils de développement, etc.

Méthode d'évaluation

La procédure d'évaluation quand un programme est rendu s'effectue de la manière suivante::

1. Exécution du programme d'dentification des similarités avec les autres travaux. Les travaux à fortes similarités sont exclus de l'évaluation.
2. Lecture rapide du compte-rendu pour trouver les commandes de lancement et le manuel d'utilisation du programme.
3. Lancement de l'exécution du programme rendu avec le jeu de test fourni. Si le programme fonctionne, l'évaluateur est déjà dans des dispositions favorables. Autrement, la suite est faite au pas de charge et la note est mauvaise (<10).
4. Evaluation du résultat produit.
5. Lecture du rapport sur les caractéristiques mis en avant par l'étudiant.
6. Etude du code rendu et rapprochement par rapport au rapport rendu.

Conseil: faites tout ce qui est possible pour simplifier le travail de l'évaluateur. L'évaluateur est un humain qui reste soumis à des humeurs :-).

Maintenant que vous connaissez la procédure d'évaluation à vous de rendre le meilleur dossier pour l'évaluation de vos travaux.

Barème d'évaluation

L'évaluation du rapport se fera sur les critères suivants:

Conditions pour l'évaluation des travaux

L'évaluation est faite si TOUTES les conditions ci-dessous sont remplies. Autrement, l'évaluation n'est pas effectuée et la note nulle est attribuée.

1. Remise d'un fichier unique pour l'ensemble des travaux.
2. Le format du mini rapport est pdf ou txt.
3. La longueur du compte-rendu est limitée à 5 pages maximum.
4. Le contenu est original (dans le sens personnel). L'originalité signifie que l'Indice de similarité est faible.
5. Le contenu rédactionnel est effectué par un seul auteur (par défaut). Sauf si l'enseignant a explicitement donné des instructions différentes.
6. Le tar file est rendu sur le serveur de remise moodle avant la date limite.
7. Respect de la convention de nommage.
8. Présence à la séance de TP.

Remise des travaux

Avant de remettre vos travaux, il convient de les préparer.

Le compte-rendu, les codes développés et les jeux de tests doivent être mis ensemble dans un répertoire sur votre machine. Le compte-rendu sera mis sous le format pdf ou txt. Le répertoire se nommera impérativement selon ce format:

<PrenomNom>

Par exemple, l'étudiant Mimile Dupont en Master M1 nommera son répertoire: MimileDupont. Les noms de fichiers utilisés dans le répertoire ainsi que le répertoire lui-même ne doit comporter aucun espace, caractère accentué, caractère spécial ( &, *, > etc.).

Ensuite ce répertoire sera mis sous forme d'un archive compressée (suffix tar.gz) (pour les détails voir le man tar). Le nom du fichier tarfile doit être construit selon les mêmes règles que le nom du répertoire (en code ASCII uniquement, cela veut dire sans les caractères accentués):

<PrenomNom>.tar.gz

Enfin la remise effective de vos travaux peut commencer. La méthode de remise utilise la plateforme de cours moodle. Toutes autres formes de remise ne sont pas prises en compte notamment l'envoi du fichier en pièce jointe à un e-mel (et ce pour n'importe quelle raison). Les liens de remise sont indiqués sur la page du module.

Note sur les noms informatiques

Afin de limiter ces problèmes et de faciliter les échanges de données entre systèmes d'exploitation différents, il est sage de suivre ces quelques conseils de nommages de fichiers et dossiers. Ces éléments sont valables quelque soit le système d'exploitation et/ou le système de fichiers de votre ordinateur. Lorsque vous attribuez un nom à un dossier ou à un fichier, pensez à respecter les règles suivantes :

• évitez d’utiliser :
  • les caractères accentués (é, è, ê), le tréma (ë), et la cédille (ç),
  • les virgules et les parenthèses,
  • les points, réservés à l’extension du fichier (ex. .doc .pdf .xls),
  • les caractères spéciaux et réservés ( " # / \ ^ | [ ] < > % * ) et ( ; / ? : @ = & ),
  • les mots vides (le, la, les, un, une, des, ma, mon, mes, et, ou, ...) ne donnant pas plus de sens au titre et occupant
  • de l’espace inutilement.
• limitez la longueur des noms de fichiers ou dossiers.
• n'utilisez pas d'espace. Les majuscules peuvent aussi jouer le rôle de séparateur d’éléments (ex : CalendrierEstival2009.doc)