Conseils généraux pour la soutenance de projet

1 Préambule

Le but de votre soutenance est de montrer que :

- Vous avez réellement travaillé pendant 6 mois dans une équipe de projet.

- Vous pouvez expliquer clairement le problème à résoudre.

- Vous pouvez expliquer clairement la solution apportée et justifier vos choix techniques.

La clarté de l'exposé est essentielle.

Pour traiter tous les paragraphes du plan type, il faudra être bref, ne pas chercher à tout dire et avoir réellement travaillé en groupe.

Vous devez vous entraîner et mesurer le temps nécessaire à chaque partie du discours afin de faire les choix judicieux pour un exposé équilibré et compréhensible. Chaque étudiant choisit le contenu de son exposé et en est seul responsable !

Comme on ne peut tout dire, à tout niveau on peut énoncer de façon concise et claire l'ensemble du travail accompli concernant ce niveau, puis de dire "J'ai choisi d'expliquer ici le cas XXX pour son intérêt plus particulier qui est …blabla…"

Durant tout l'entretien :
- Rester positif

- Centrer l'exposé sur votre travail


1.1 DIRE BONJOUR ET SE PRESENTER

Inutile de dire que vous êtes en IRIS à votre lycée le jury le sait !

1.2 SE SITUER DANS LE PROJET

Se situer dans le projet, puis dans le sous-système.

1.3 PROJETER LE PLAN DE L’EXPOSE SUR UN

On peut aussi le distribuer sur feuille de papier où l’on mentionnera son NOM et sa responsabilité dans le projet.

1.4PARTIR DES DOCUMENTS UML

Construire l'intervention à partir des documents UML de capture des besoins, d'analyse et de conception.

Il est très mal vu de rentrer dans l’implémentation au bout de 2 minutes en expliquant la réalisation en C++ au lieu de la structure logique du problème et de sa solution.

1.5 DESCENDRE JUSQU'AU NIVEAU CHOISI

En 3 minutes, amener le jury progressivement et intelligemment sur les points que vous avez choisi d’exposer (de préférence vos points forts).

Comme vous n'avez pas le temps de tout expliquer, il est permis de dire: "J’ai choisi de vous exposer le point suivant"

Attention il est obligatoire de traiter un sujet dans ses différents niveaux :

- capture des besoins

- analyse

- conception

Vous ne pouvez pas choisir d’expliquer uniquement la conception détaillée ou le code par exemple car cet exposé hors contexte serait incompréhensible donc très mal apprécié.


1.6 INSERER L'EXPOSE TECHNIQUE

(Analyse, Conception Générale et Conception détaillé)

Analyse (QUOI ? le problème)

Conception générale (COMMENT ? la solution)

· Si un mécanisme est délicat ou particulièrement intéressant, et si vous maîtrisez, vous pouvez insérer un paragraphe conception détaillée.

· Présenter l'ensemble du travail (si nécessaire jusqu'au codage mais il vaut mieux éviter).

· On peut décider d’approfondir un point particulièrement intéressant. Attention au chronomètre.

1.7 CONCLUSION TECHNIQUE (1 minute)

Conclusion sur l'exposé technique -> faire le point sur votre travail

- ce qui a été réellement fait

- ce qui reste à faire

- intégration dans le projet

1.8 CONCLUSION GENERALE (1.5 minute)

Conclusion générale pour terminer l'entretien. Que m'a apporté le projet ... Ce que j'ai appris d'original.

Eviter les banalités! On peut parler des difficultés rencontrées, surmontées ou non.

Elargir le débat pour montrer qu'on a réfléchi à sa mission

Ce qu'il est possible de réaliser dans un futur proche.

Ce qu'il serait envisageable dans un futur plus lointain.

Signaler la fin de l'exposé.

"J'ai terminé mon exposé. Je vous remercie de votre attention."

1.9 DIRE AU REVOIR EN PARTANT



2 Quelques règles élémentaires

Enfin 5 règles de bon sens élémentaire pour ceux qui en manqueraient :

Règle N° 1 Le jury a toujours raison. (Quand le jury n’a pas compris, c’est que vous n’avez pas bien expliqué…)

Règle N° 2 Quand le jury a tort, se reporter à la règle numéro 1.

Règle N° 3 Rester POSITIF et extraire de vos échecs une expérience utile pour l'avenir.

Règle N° 4 Ne pas démolir les copains. Le projet comme tous les travaux industriels, est un travail d’équipe et vous devez vous y insérer harmonieusement. L’industriel du jury doit avoir envie de vous embaucher et de vous introduire dans son équipe.

Règle N° 5 Ne pas démolir les professeurs. Le jury est composé de professeurs qui ont exactement les mêmes problèmes que vos professeurs avec leurs propres étudiants. Très probablement, le jury n'interprétera pas vos paroles comme vous pourriez l'espérer ! Il est beaucoup plus rentable de montrer qu'on a envie de travailler dans l'industrie, que l’on aime mettre en oeuvre de nouvelles connaissances et éventuellement qu’on sait tirer la leçon de ses échecs.


Exposé : 20 min. Démo sur cible : 20 min.


3 Plan indicatif d'un exposé bien construit pour l'analyse en UML

Présentation Commune :la capture des besoins (6 à 8 minutes)

1/ Le cahier des charges

QUOI : je présente d'abord le problème

Objectif : Pourquoi fait-on ce projet ?

Présenter l’entreprise cliente (2 phrases). Quelle est la raison d'être du projet. (2 ou 3 phrases). Enoncer les objectifs principaux. (1 phrase par objectif = [sujet] verbe complément.

2/ Le synoptique de l'application

OU et COMMENT : je présente la solution matérielle (c'est plus concret)

Objectif : Illustrer concrètement le contexte du problème et de sa solution

Commenter le synoptique fourni par les profs dans le cahier des charges ou votre synoptique s'il est plus clair.

3/ Le diagramme de contexte

QUI est concerné par le problème et la solution

Objectif : Illustrer abstraitement le contexte du problème et de sa solution

Présenter brièvement les acteurs principaux puis les acteurs secondaires autour du système à construire. Le diagramme de contexte délimite le travail à effectuer grâce à la nature des messages échangés.

Présentation Personnelle :Analyse et Conception (12 à 14 minutes)

Chaque concept doit être illustré par un diagramme UML comportant un titre et commenté par l’étudiant.

4/ Se situer dans le projet grâce au DCU

Transition entre la présentation générale et mon travail personnel

Le Diagramme des Cas d'Utilisation (DCU) du système est la table des matières du mode d'emploi du système

En commentant le DCU, mettre en évidence pour chaque CU qui vous concerne :

- Le rôle des acteurs principaux

- Le rôle des acteurs secondaires (dispositif matériel ou logiciel participant à la satisfaction des besoins exprimés)

5-a/ Se situer dans les paquetages du projet

Organisation et répartition du travail

Objectif : SITUER votre intervention dans l'architecture logicielle du projet.

5.1 Présenter votre paquetage et ses responsabilités (4 ou 5 mots par phrases).

5.2 Expliquer très brièvement ses relations avec les autres.

5-b/ Détailler les CU qui vous concernent

Objectif : Détailler le scénario nominal.

5.1 Extraire du DCU général le cas d’utilisation avec les acteurs concernés.

5.2 Commenter la Séquence du scénario nominal avec système « non zoomé ».

5.3 Commenter le Diagramme d’activité du CU avec les enchaînements alternatifs et exceptionnels si intéressants.

Note : Il n’est pas indispensable de balayer tous les CU. Au moins l’un des 2 diagrammes 5.2 ou 5.3 doit être commenté.

6/ Votre analyse détaillée = le QUOI

J’explique le problème à résoudre avec les concepts du client (regroupé par CU)

- L'analyste utilise les concepts et le vocabulaire du métier du client pour parler du problème à résoudre.

- En partant de chaque cas d’utilisation, présenter les principales classes d'analyse (frontières – contrôle - entités)

- les classes (les noms du cahier des charges) et leurs responsabilités,

- les relations (les verbes du cahier des charges) entre les classes

7/ Votre conception = le COMMENT

J’explique ma solution informatique (toujours regroupé par CU)

- Le concepteur y rajoute les concepts et le vocabulaire des informaticiens pour parler de la solution adoptée.

- Commenter les diagrammes des classes de conception :

nouvelles classes introduites pour résoudre informatiquement le problème. Distinguer classes actives/classes non actives.

- Présenter le diagramme de communication (collaboration) des classes actives en tenant compte des stratégies d’échange/synchronisation (producteur/consommateurs, section critique,…) et des outils IPC (sémaphore, activation, signaux, événement, mémoire partagée etc.)

- Présenter le ou les diagrammes de séquence les plus intéressants.


8/ La Conception détaillée

S'il reste du temps et si je veux briller (ou me ramasser…)

- S'il existe des parties délicates qui méritent une explication supplémentaire.

- S'il existe des points de détails particulièrement intéressants

- Les explications doivent être fournies en UML par ex. diagramme de séquence si l'on veut mettre l'accent sur le séquencement des messages ou diagramme de communication si l'on veut illustrer les relations entre classes.

- Inutile de montrer du code : si le jury veut voir le code ou s’il veut vous interroger dessus, il fera durant la phase d'interrogation ou la démo sur cible. Vous n'avez que 10 minutes (revues) ou 20 minutes (soutenance)

- Attendez-vous à des reproches sévères s'il n’y a pas de traçabilité entre la capture des besoins, l’analyse, la conception et le code.

- Attendez-vous à des reproches sévères si le code n'est pas commenté.

9/ La Conclusion

Appliquer les points 6 et 7 des conseils généraux.


4 Liste en vrac des évidences souvent oubliées par les étudiants

Relire le chapitre qualité du cahier des charges

Dans le dossier de projet, le travail de chaque étudiant doit être clairement identifié par un pied de page comportant le nom de l’étudiant responsable et le sous-système ou paquetage concerné.

Documents projetés ou affichés

- Un schéma au vidéo projecteur n’est pas toujours très lisible -> Pour tous les schémas UML et autres, toujours les situer dans le dossier grâce à un numéro de page écrit sur la diapositive et de préférence noté toujours au même endroit et dans une même police/couleur. (Vous montrer ainsi que vous avez préparé votre exposé !)

- La pagination des documents est souvent bâclée quand le document est fabriqué trop tard (= dernier jour autorisé…).

- Si les documents ne figurent pas déjà dans le rapport de projet, il peut être utile de les distribuer au jury (prévoir 3 feuilles + 1 pour vous)

- Vérifier avant la soutenance si la police employée et l’épaisseur des traits de votre présentation permet une bonne lisibilité au vidéo projecteur.

Il doit rester quelque chose de votre intervention :

- au minimum le plan de l'exposé,

- éventuellement quelques documents inédits avec votre nom et votre fonction dans le projet,

- inutile de noyer le jury avec des corrections de dernière minute. Vous aviez 6 mois pour les introduire dans le document du projet.

Toujours illustrer son travail à l’aide des diagrammes UML.

Dans le dossier de projet, chaque diagramme UML doit être accompagné impérativement d’un commentaire explicatif qui explicite les rôles des acteurs, des classes, des messages, des paquetages, etc. Les commentaires en français (POURQUOI-QUI-QUOI-COMMENT-OU-COMBIEN) et les diagrammes en UML (QUI-QUOI-COMMENTCOMBIEN) sont complémentaires et indissociables. Qu’on se le dise !

Dans le dossier de projet, chaque diagramme doit avoir un titre INFORMATIF qui indique ce qu’il documente. Exemple de titre NUL : « Diagramme de Classe ». Ce titre n’apporte rien au lecteur à part le sentiment d’être pris pour un … ignare en UML, sentiment qu’il n’est pas très judicieux de distiller quand on s’adresse à un jury d’examen. Exemple de titre INFORMATIF et résumant bien l’information apportée : « Hiérarchie des alertes ».

Dans le diaporama de la soutenance, chaque diagramme doit avoir le même titre INFORMATIF que celui du dossier. Par contre, le commentaire ne doit jamais apparaître. Au contraire, c’est ce texte qui vous sert de base pour commenter la diapositive au jury. Ces commentaires doivent être appris par coeur et répétés au moins 3 fois devant magnétophone (s’il refuse… Poubelle !) et 3 fois devant vos copines. (si elles refusent… Changez de copines !).

Sur une diapositive, on a le droit à :

- soit un résumé de texte => 1 sujet + quelques concepts importants résumés [verbe infinitif+complément]

- soit un diagramme UML avec son titre.

Dans les 2 cas, les commentaires sont appris par coeur et n’apparaissent jamais à l’écran.

Pour présenter un diagramme de classe, il vaut mieux commencer par un diagramme de haut niveau (conceptuel -> Nom de la classe + mission de la classe qui se décompose en responsabilités) avant de présenter un diagramme de bas niveau (implémentation -> attributs + opérations).

La mission et les responsabilités peuvent se placer dans le 2ème ou 3ème compartiment en tant que commentaire donc précédé de -- (double tiret)

Pour justifier une association du diagramme de classe de façon élégante, on peut expliquer une ou plusieurs interactions intéressantes sur un diagramme de communication ou de séquence.

Un choix dans un menu d' IHM correspond en phase d'analyse à l'envoi d'un message par l’IHM (objet frontière) vers un objet Contrôle ou un objet d'analyse fournissant le service attendu.

Vous pouvez préparer des diapos ou transparents supplémentaires pour la partie « Interrogation ». Pensez à classer astucieusement vos documents et vos programmes afin de ne pas vous enliser en temps réel.

Un chronogramme (en UML 2.0 -> diagramme de timing) peut illustrer votre propos et faciliter une explication.

Préparer une démonstration sur le matériel en rapport avec l'exposé.



Rigueur du vocabulaire et de l’attitude :

Utiliser un vocabulaire correspondant à une formation de 2 ans en Section de Techniciens Supérieurs.

Evitez les mains dans les poches.

Evitez de dire aux examinateurs « Je ne vais pas vous expliquer cela car c’est trop compliqué et vous n’allez pas comprendre … »

On ne dit pas « une bagnole » mais « une voiture ».

On ne dit pas « C’est l’histoire d’un mec …» mais « Il s’agit d’un vigile… ». Vous n’êtes pas Coluche !

Etre clair :

- Toujours présenter un problème avant sa solution.

- Justifier les choix de conception ou d’implémentation. (Étude comparative)

- Donner la signification des acronymes barbares et peu connus du genre DSN, ADO ou ODBC.

- Un entraînement à l’exposé oral devant des copains ou copines est toujours bénéfique ne serait-ce que pour calibrer son temps de parole et pour se forcer à être clair. On est beaucoup moins stressé devant un jury si c’est la 3ème fois que l’on expose la même chose…

- L’exposé doit être préparé par écrit puis appris par coeur. Il est utile d’avoir devant soi le jour de l’oral le plan écrit en grosses lettres lisibles (et éventuellement un court résumé).

Pas trop de détails

- Ne pas entrer trop dans les détails d’implémentation, sauf sur demande de l’examinateur en 3ème partie de l’épreuve.

- Au lieu de montrer tout de suite des tables ACCES ou EXCEL, il vaut mieux projeter la modélisation conceptuelle de la base de données. (Classes et Associations…) puis éventuellement l’implémentation sous forme de tables.

Les tests de mise en oeuvre, les tests unitaires et les tests d’intégrations partielles

- Tenir à la disposition des examinateurs les différents tests et la liste ordonnée de ceux-ci. Vous pouvez mentionner cela en début de démonstration.

- Une séquence progressive et bien conçue de tests d’intégration pour amener à la démo d’intégration finale peut servir à montrer que vous savez travailler intelligemment.

·- Il est souhaitable que vos répertoires soient ordonnés numériquement : « 01 – xxxx », « 02 – aaaa », « 03 – uuuu » …

Le Code de l’Annexe Technique du Dossier de projet (Malheur à qui oublie ces évidences !)

- Traçabilité : Le jury doit pouvoir retrouver dans le code, tous les concepts introduits dans les documents d’analyse et de conception. En particulier, le nom des packages, des classes, des attributs et des méthodes doivent être les mêmes que ceux choisis en UML. Les tests de validations doivent bien évidement refléter les cas d’utilisation énoncés dans la capture des besoins et correspondre à des chemins bien définis des diagrammes d’activités. Les automates de contrôle implémentés dans le code final doivent correspondre aux diagrammes d’état UML. Les commentaires référençant les diagrammes UML par leur nom et habilement dispensés dans le code sont toujours les bienvenus.

- Un commentaire doit expliquer de préférence pourquoi une opération est exécutée plutôt que d’expliquer que ce que fait le code en paraphrasant le code. Contrairement aux étudiants, les examinateurs et les programmeurs professionnels savent lire du code informatique mais ne connaissent pas forcément l’intégralité du cahier des charges et/ou les innombrables détails du matériel ou des API. Donc expliquer POURQUOI.

- Quand du code est visiblement incompréhensible car vous ne maîtrisez pas le vocabulaire ou la forme, vous devez bien évidemment commenter le QUOI et le COMMENT en plus du POURQUOI.

5 Sur la forme de la soutenance

Le plan se limite à 2 ou 3 niveaux.

Les titres sont en rapport avec le fonctionnel et jamais la typologie UML.

L’exposé s’appuie sur des diapositives.

Les phrases écrites doivent être courtes et peu nombreuses.

Les commentaires associés sont extraits du dossier technique.

Les figures projetées doivent toujours être très lisibles. On utilise pour cela l’application la plus adéquate (PowerPoint ou Visio ou autre …)

L’esprit humain comprend mieux un discours s’il est ordonné avec bon sens. Les examinateurs aussi…

Toute partie du discours peut être structurée en suivant la règle de l’ S.P.R.I.

Situation: Il faut situer le contexte de l’exposé qui va suivre.

Problèmes: Quels sont les problèmes qui se présentent dans cette situation

Résolution: J’expose la solution choisie (choix et justifications)

Informations: Complémentaires (détails qui gêneraient l’exposé principal)

En tout cas bonne chance!

haut de page
BTS Informatique