Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Comment rédiger un compte rendu de TP dpt Telecom, Tanguy Risset et les enseign

Comment rédiger un compte rendu de TP dpt Telecom, Tanguy Risset et les enseignants AGP/SDE Un compte rendu de TP est un document destiné : – à faciliter la compréhension du code pour le correcteur – à expliquer et justiﬁer la démarche suivie lors de l’implémentation – à mettre en valeur votre travail 1 Le fond Ce document sera lu avant de parcourir le code, il doit donc comporter une analyse du problème, une conception détaillée de la solution, puis une explication de la réalisation, une description des tests effectués et enﬁn un retour sur expérience. analyse du problème Le rapport comportera une introduction rapide au problème mais il est inutile de rappeler longuement le sujet, une ou deux phrases sufﬁsent en général. Dans l’analyse du problème, vous précisez votre interprétation de certains points qui vous ont semblé ﬂous dans le sujet. Vous com- plétez le cahier des charges de manière à ce que la solution que vous recherchez soit complètement spéciﬁée. conception de la solution Il faut amener progressivement le lecteur à comprendre la solution que vous proposez. Pour cela vous êtes amenés à proposer un découpage du problème en sous-problèmes et à proposer des solutions pour résoudre ces sous-problèmes. Ces solutions peuvent être des algorithmes mais aussi des structures de données ou des choix pour restreindre l’espace des conditions d’utilisation. Pensez aussi à relier les sous-problèmes entre eux : comment les résultats d’un sous-problème sont utilisés par un autre sous-problème. Un schéma est souvent utile à ce niveau (il existe des approches plus formelles, UML par exemple, lorsque l’on aborde des problèmes plus gros). Chaque algorithme, doit être décrit précisément et justiﬁé : quels auraient été les autres choix pos- sibles ? quels sont les avantages et les inconvénients d’un tel choix ? Quel est la complexité (en temps, en mémoire) ? Quels sont les impacts sur la fonctionnalité ﬁnale (par rapport, par exemple au cahier des charges complété) ? Cette partie ne doit pas contenir de code, elle doit pouvoir être utilisée pour une réalisation dans un autre langage impératif. Vous aurez ici à mentionner les structures de données mais en restant au niveau logique : les listes, les piles, les tableaux, tables de hachage etc... sans détailler la manière dont seront implémentées ces structures de données. Le plus important est que le texte se lise bien, l’enchaînement logique des idées amenant naturelle- ment à la compréhension de la solution. C’est une décomposition top-down, c’est à dire que l’on part du problème global que l’on décompose et on décrit ensuite les solutions pour chacun des sous-problèmes. Réalisation Le rapport doit comporter les listing complets du code, mais en annexe (ils ne comptent pas dans le nombre de pages). Cette partie doit expliquer l’implémentation de la solution que vous avez proposée, structures de données détaillées, implémentation des algorithmes, éventuellement rôle de certaines variables clés, etc. La décomposition en fonctions doit se rapprocher de la décomposition proposée dans la partie conception. Là encore les choix doivent être justiﬁés, éventuellement en relatant des problèmes apparus avec d’autre choix. 1 Test C’est une phase importante du développement, plus vous testerez votre implémentation plus le lecteur sera convaincu de sa validité. Indiquez précisément quelles fonctionnalités sont testées, quelle est l’infrastructure de test utilisée (mise en place de test automatique dans le makefile ou tests à la main). Il est, en général, assez précieux de pouvoir ré-exécuter tous les tests de manière à vériﬁer la compatibilité du code au cours de l’évolution du logiciel. Plus cette phase de test est prévue tôt dans le processus, plus elle sera efﬁcace. Retour d’expérience Évitez les généralités du style “nous avons beaucoup appris lors de la réalisa- tion de ce TP”... Mentionnez éventuellement les problèmes rencontrés. Un bilan des efforts fournis (en terme de temps passé à la conception, à la réalisation et à la rédaction ou même en terme de recherche d’informations) doit également vous permettre de situer le rapport effort/retour et d’évaluer le coût de ce projet. C’est une étude critique de votre travail, plus elle est perspicace, plus le lecteur est convaincu que vous avez compris les problèmes. 2 La forme La taille des différentes sections mentionnées ci-dessus dépendra évidemment du nombre de pages du document. En général un nombre de pages maximum est indiqué, il ne faut pas le dépasser. Il n’y a pas obligation de faire autant de page, mais en général lorsqu’on demande au plus 5 pages, il est assez mal vu de rendre un compte-rendu de 2 pages. Pour cela il est important de prévoir précisément à l’avance le plan détaillé de votre document aﬁn que vous puissiez inclure toutes les informations importantes, les informations secondaires n’étant rajoutées qu’après, selon la place disponible. Page de garde N’oubliez rien : titre TP, nom des étudiants (bien visibles), groupe, matière, départe- ment, date, puis le plan du document. Quelques remarques sur la forme – Pensez à faire des phrases complètes (plus facile à lire que les listes d’item, donc pas comme ici jus- tement...). Organisez votre texte en paragraphes de plusieurs lignes. Évidemment, une grammaire et une orthographe correctes sont fondamentales, sans elles le lecteur ne peux pas se concentrer sur le fond. – L’utilisation de ﬁgures facilite souvent la compréhension et aère le document. Une ﬁgure doit comporter une légende qui permet au lecteur de la comprendre sans qu’il ait obligatoirement lu le texte associé (de manière générale, ayez à l’esprit que beaucoup de documents que vous rédigerez seront seulement parcourus rapidement). Une ﬁgure doit normalement être référencée depuis le texte. – Utiliser une fonte différente (courrier par exemple) pour le code. Éviter l’utilisation du gras, préférez l’italique pour mettre en avant un mot. – En ce qui concerne le code, une bonne indentation est indispensable. Les commentaires sont bons si ils aident effectivement à mieux comprendre le code (et ne se contente pas de paraphraser le code). – Pour aller plus loin, il existe des règles de typographie très précises en Français, qui sont res- pectées par exemple dans les journaux quotidiens. Jacques André a écrit un document assez court recensant les principales erreurs commises (“petites leçons de typographie” disponible sur http://jacques-andre.fr/faqtypo/lessons.pdf), je vous conseille fortement ce docu- ment dont l’utilité ira bien au delà des compte-rendus de TP. 3 Conclusion Les conseils ci-dessus n’ont aucun caractère obligatoire, mais ils sont en général respectés dans les bon rapports. Ils ne sufﬁsent pas non plus à faire un bon rapport. La qualité essentielle d’un bon rapport est qu’il se lise naturellement et qu’il explique de manière claire les difﬁcultés de compréhension du code. 2 uploads/Ingenierie_Lourd/ cpt-rendu-tp.pdf