1°/ Objectif
Le but de cette soutenance est de faire un bilan complet de votre projet dont le coeur sera une démonstration. Le contenu reprend en gros les principes de la SAÉ IHM : vous devez convaincre votre patron que vous avez "bien travaillé". Cependant, contrairement à la SAÉ du S2 :
- le patron a juste lancé une idée très vague d'application (du genre "si on développait une appli. pour surveiller la qualité de l'air, on aurait des clients potentiels"),
- il vous a imposé de partir d'un prototype d'architecture logicielle qu'il a lui-même produit il y a quelques années, parce qu'il veut comprendre votre résultat.
- il n'espère pas forcément un produit vendable, mais plutôt un "proof of concept" (POC) fonctionnel avec du vrai matériel.
C'est pourquoi cette soutenance doit essentiellement :
- présenter honnêtement ce POC, avec ce qui est fonctionnel ou non, les améliorations, ...
- mettre en avant vos compétences, qu'elles aient été acquises ou non durant ce projet, pour convaincre votre patron que vous avez mérité (... ou pas) votre salaire pour produire ce POC,
2°/ Format
La soutenance dure au maximum 25 minutes, avec une structuration libre. Vous pouvez donc découper le temps comme vous le voulez, avec par exemple une seul grosse démonstration puis un bilan, plusieurs petites démo entrecoupées de commentaires sur transparents, etc. Cette liberté est à la fois une aide car elle vous permet de prendre en compte les spécificité de votre application et de votre équipe, mais aussi un piège car vous pouvez choisir un format qui nuira à la compréhension, surtout si vous préparez mal votre soutenance. La seule contrainte est que la démonstration doit se faire en direct, et qu'elle doit aborder toutes les fonctionnalités principales.
Afin de prendre en compte les remarques de la première section, vous devez considérer que le jury sera constitué par une partie du staff directeur de votre entreprise, ce qui implique un degré de compréhension du côté technique très variable. Malheureusement pour vous, vous devez convaincre que votre POC est viable aussi bien ceux qui comprennent la technique que ceux qui n'y connaissent rien, voire même certains qui ne connaissant pas du tout votre projet. C'est pourquoi, vous devez :
- décrire les objectifs de l'application, ses acteurs, en vous appuyant fortement sur des scénario plausibles et intéressants pour présenter des cas d'utilisation, et ce de façon vivante (c.a.d. pour convaincre que votre POC sert réellement à quelque chose et qu'il faut financer sa mise en prod).
- parler des challenges techniques et comment ils ont été résolus, sans pour autant présenter le comment en terme informatique (par ex, jamais de code). Par exemple, pour la partie analyse média, cela implique de décrire les problématiques d'analyse, quelles solutions logicielles/matérielles ont été étudiées pour les résoudre avec leur avantages/inconvénient, pourquoi on a choisi l'un d'entre elles, etc. La présentation de ces challenges est également l'occasion de présenter les compétences nécessaires à leur résolution, et d'illustrer par exemple celles qui ont été acquises et/ou renforcées au cours du projet.
- présenter un bilan fonctionnel qui explique clairement le pourquoi de certaines limitations ou de points non implémentés, ou partiellement (manque de temps, trop ambitieux, pas assez de travail, manque de compétence, etc.).
- présenter un planning de finalisation si le POC n'est pas complet, en le justifiant, notamment par rapport à votre degré de connaissances/compétences nécessaires pour terminer ce qui manque.
- donner des perspectives sur le passage à une version vendable du POC ou bien des améliorations utiles, qui soient pertinentes par rapport à vos compétences. Vous devez ainsi prouver que vous êtes déjà prêt à prendre en main cette nouvelle phase.