Les rendus¶
A. Le cahier des charges¶
1. Présente le contexte du projet¶
Il est composé d'une première partie qui décrit le projet et le place dans son contexte. Elle est rédigée et correspond à comment est-ce que vous présenteriez le projet à l’oral à quelqu’un qui ne le connaît pas du tout. Le but est qu’on arrive à en comprendre l’objectif global.
2. Décrit les différentes fonctionnalités du programme¶
La deuxième partie décrit les fonctionnalités principales que le programme devra réaliser. Elle est plus précise que la première, et distingue ce qui est réalisé par l’ordinateur de ce qui est fait par l'utilisateur.
B. Le programme¶
1. Implémente les bonnes pratiques¶
Votre programme doit être lisible par un autre programmeur : si celui-ci voulait effectuer des modifications, il devrait être en mesure de le faire. Cela implique d’implémenter les bonnes pratiques de programmation courantes : noms des variables et des fonctions explicites, rôle des fonctions commenté, parties difficiles du code également commentées, découpage en fonctions.
La cohérence aide aussi à la lisibilité : écrire tous les noms avec la même convention (soit des _, soit des majuscules pour séparer les mots), dans la même langue, etc.
2. Est facile à utiliser¶
L’utilisation de votre programme ne doit pas demander à l’utilisateur de se demander comment faire pour le lancer et utiliser ses différentes fonctionnalités : ceci doit être explicité dans un fichier de documentation de type readme. Comment lancer le programme et comment accéder aux différentes fonctionnalités doit y être expliqué.
Il ne doit pas être difficile de trouver l’information, elle doit apparaître clairement.
C. Le rapport¶
Le rapport contient 2 parties. La 1ère peut être collective, la 2ème doit être individuelle.
1. Contient une description fonctionnelle du projet¶
La description fonctionnelle reprend les fonctionnalités décrites dans le cahier des charge, et les précise : elle indique le nom de la ou des fonctions qui réalise chaque fonctionnalité, le fichier dans lequel elle(s) se trouvent, et si cette fonction provient d’une bibliothèque. Si d’autres fonctionnalités ont été ajoutées, il faut également l’indiquer.
Elle décrit comment les différentes fonctionnalités interagissent entre elles : quelle fonction/programme est appelé(e) par quel(le) autre ?
L’objectif est d’indiquer comment les objectifs du cahier des charges ont été remplis.
2. Fait un bilan critique de ce qui a été fait¶
Une deuxième partie indique ce qui a pu être réalisé et, par rapport au cahier des charges, ce qui a été abandonné et pourquoi.
Il décrit les difficultés rencontrées et les solutions choisies, et conclut sur ce qui pourrait être amélioré.
Cette partie fait entre 5 et 10 lignes.
D. La soutenance¶
La soutenance est une présentation de 7-8 min pour un projet fait à 2, de 10-12min pour un projet fait à 3, 15min pour un projet fait à 4.
1. Présente le projet¶
Votre soutenance doit permettre à un auditoire qui ne connaît pas votre projet de le comprendre : le contexte doit être bien amené (présentation générale, s’appuyant sur le cahier des charges), les fonctionnalités de votre programme doivent être décrites sans entrer trop dans le détail du code (difficile à expliquer à l’oral). Il vous est néanmoins possible d’en présenter des parties importantes, en précisant comment cette(ces) partie(s) s’intègre(nt) à l’ensemble.
2. Soutient les choix effectués¶
Vous devez aussi revenir sur le déroulement du projet et argumenter sur les choix effectués, en vous appuyant sur le bilan critique de votre rapport. Il s’agit des choix techniques, et des choix effectués pour la gestion du projet.