La soutenance est une épreuve orale ayant lieu après le dernier TP, et qui doit être effectuée au plus tard une semaine environ après les épreuves écrites de MIA09 (la date précise sera spécifiée plus tard, en TP). Il s'agit d'une épreuve orale qui se passe par groupe. Vous prenez rendez-vous avec moi (mes coordonnées sont dans l'introduction), et nous convenons de la date et de l'horaire où la soutenance aura lieu. Usuellement, cette soutenance se déroule en salle de TP (U3-208). Je vous demanderais de bien vouloir me prévenir assez tôt si vous avez un empêchement pour honorer le rendez-vous, puisque je ferai personnellement de même de mon côté. Vous devez venir avec un listing de votre projet, une documentation utilisateur, et (de manière optionnelle pour les groupe de 2, conseillée pour les groupes de 3 et obligatoire pour les groupes de 4) une documentation programmeur de votre logiciel. La soutenance en elle-même dure environ 1 heure et se déroule en trois étapes.

6.1 Question de cours

  Je commence par vous faire tirer chacun un sujet parmi les aperçus théoriques vus en première partie. Vous vous partagez le tableau, et vous avez 10 minute de préparation, au bout desquelles je vous demande de me faire un bref exposé oral de ce que vous avez retenu sur le sujet. Je dis « bref », car un discours d'un quart d'heure est déplacé dans ce genre d'épreuve, et j'insiste sur « oral », c'est à dire que vous n'êtes pas là pour lire tout ce que vous êtes parvenus à écrire sur un aussi petit tableau en l'espace de 10 minutes. Ce que vous écrivez au tableau doit être un support de votre discours, et donc être utilisé comme un transparent, c'est à dire en tant qu'illustration de ce que vous exposez. Essayez d'être clair(e) et assuré(e) dans votre élocution - un principe éternel est qu'il vaut mieux connaître 50% du cours et faire passer 100% de ce que l'on sait que connaître 100% du cours et n'en faire passer que 25% !

6.2 Correction du projet

  Dans une seconde étape, on étale votre listing sur la table, on le lit et je le corrige, en vous expliquant au fur et à mesure ce qui me convient ou ne me convient pas dans vos choix et en griffonnant en rouge sur votre listing. Non, en général, je n'exécute pas vos projets, et ceci pour deux raisons : d'abord, parce qu'en le lisant je vois assez précisément à quoi peut ressembler l'exécution de votre programme, et ensuite et surtout parce que la lecture du listing m'en apprend cent fois plus ; je préfère vraiment un programme bien écrit qui ne fonctionne pas suite à une broutille ou un malheureux concours de circonstances (modem défectueux, etc.) qu'un programme qui fonctionne miraculeusement alors qu'il a été écrit n'importe comment !!!

6.3 Travail sur le projet

  Une fois le programme corrigé, vous repassez tous au tableau, chacun avec un petit bout de code à écrire. En général, je vous propose comme sujet de traiter la correction d'un « bug » de votre programme. Si vraiment vos erreurs ne me semblent pas suffisamment intéressantes pour donner lieu à quelques minutes de programmation, je vous propose une extension possible de votre programme. Dans tous les cas, cette programmation est très simple et ne dépasse presque jamais les 4 instructions. Vous avez droit à votre listing pour vous aider. Le but est de prouver que vous connaissez votre code. Il y a toujours, dans un groupe, une ou deux personnes qui ont tendance à s'accaparer le clavier plus que les autres (surtout dans les groupes de quatre, où la production de la documentation peut occuper une personne à part entière), et ce n'est pas anormal : vous n'allez pas vous diviser le clavier en quatre zones, chacun tapant les caractères de sa zone ! Par contre, ce que je recherche, c'est que ceux qui ne sont pas derrière le clavier aient quand même une très bonne connaissance du programme, de son fonctionnement et de sa structure, et sachent le montrer au tableau. Et si possible que, pendant la réalisation du projet, ils ennuient le « programmeur » le plus possible en lui demandant les raisons de ses choix. C'est excessivement formateur pour tous les deux. Par contre, au tableau, je ne vous demanderai pas de m'écrire du Turbo Pascal correct, mais plutôt d'écrire un pseudo code rapide à écrire et à lire : je ne connais pas les mêmes impératifs syntaxiques qu'un compilateur Pascal !

Voilà ! Lorsque vous ressortez de la pièce, ne me demandez pas, surtout les premiers, quelle est votre note : la plupart du temps, elle variera en fonction de ce que les autres auront fait. Certains semestres, les choses vont plus vite, d'autres moins. Je fais en sorte, pour que personne ne soit lésé, que les choses se passent de manière constante en moyenne entre les semestres. Par contre, ce que je vous demanderais, ce serait de réussir vos examens, que je n'ai pas la mauvaise surprise de vous voir débarquer le semestre suivant ! En résumé : bon courage et bonne chance à tous !