# Présentation Orale

## Structure
1. Présentation Personnelle
2. Sommaire
3. Contexte/Présentation de l'application
4. Organisation
5. Technologies utilisées
6. Spécifications fonctionnelles (fonctionnalités importantes/diagramme Use Case/User Stories)
7. Maquettes
8. Spécifications techniques (diagramme de classe/structure de l'application en MVC/etc.)
9. Explication de code
10. Démo scénarisée
11. Conclusion

L'ordre est important pour aller du général au plus technique mais on peut modifier certaines choses, par exemple parler des technos utilisées après les spécification techniques, ou alors faire la démo après les maquettes, ou les maquettes avant/pendant les spécifications fonctionnelles

## Points d'attention

### Général
* :warning: Pas trop de texte par slide, si y a un roman sur les slide soit on vous écoute pas, soit on le lit pas. Mettre plutôt des "bullet point" et ensuite c'est vous qui à l'oral développez
* Ne pas juste lire ses slides (mais si vous avez fait des bullet points, normalement ya moins de risque)
* Bien regarder le jury et pas juste son écran
* Pas parler trop vite (pour ça, faut être plus à l'aise et pour être plus à l'aise faut répéter)
* :warning: Faire relire ses slides, pas de fautes dedans
* Des screenshot de trucs oui, clairement, mais zoomés sur la partie intéressantes (sans morceaux d'interfaces qui se balladent etc.), et pas plus d'un screenshot par page (tester sur un rétroprojecteur avant, pour constater que c'est lisible ou pas)
* Ne pas trop s'attarder sur le négatif ("ça ça marche pas", "ma maquette elle ressemble pas du tout au résultat final", "j'ai utilisé ça mais j'ai rien compris", "cette partie là elle bug, chais pas pourquoi", "mon diagramme il est tout ptit et tout nul")

### Présentation perso
* Parler de soi rapidement, pas raconter toute sa vie
* On peut dire le cursus fait actuellement

### Sommaire
* Important de l'avoir pour donner directement une idée d'où on va, plus agréable ensuite d'écouter pour un juré
* Dire 2-3 mots de ce qui va être abordés dans les différents points
* :warning: Ne pas en dire trop à ce moment là (exemple: mieux vaut pas commencer à dire les fonctionnalités, ou les techno utilisées ou autre pendant le sommaire)

### Contexte/Présentation de l'appli
* L'idée est qu'après ce point, une personne qui ne vous connait pas ait compris le but de l'application que vous présentez
* Comment vous avez eu l'idée ? A qui ça peut s'adresser ? Qu'est-ce que permet de faire l'appli globalement ?

### Organisation
* Comment vous vous êtes organisé·e pour travailler
* Utilisation d'un kanban ?

### Techno utilisées
* L'idée est de lister les technos/framework/langages utilisées
* :warning: Pas faire juste une liste de courses à l'orale, le but ça sera plutôt de pouvoir dire 2-3 mots sur chaque techno ("Le back fait avec Express qui est la librairie la plus utilisée pour faire du routing en node", "TypeORM qui, comme son nom l'indique, est un ORM qui nous permet de faire le lien entre la bdd et les entités", etc.)
* On peut aussi présenter les outils utilisées (trello, gitlab...)

### Spécifications fonctionnelles
* Decrire les acteurs de l'application
* Decrire les fonctionnalités notables de l'application
* Faire plusieurs pages si le diagramme de Use case est trop grand pour être lisible en une seule (en plus ça permettra de concentrer l'attention sur ce dont vous parlez)

### Maquettes
* Présenter quelques maquettes de l'application, pas forcément toutes
* Généralement le fait de montrer la maquette desktop comparé à la maquette mobile pour indiquer les différences, c'est bien
* Faire les liens dans le logiciel de maquettage pour pouvoir présenter les maquettes de manière interactive avec zones cliquables etc.
* :warning: Avoir une slide charte graphique pour expliquer ce qu'est une charte graphique, avec pourquoi pas un screenshot de l'interface finale, peut être la liste des couleurs utilisées etc.

### Diagramme de classes
* Parler des relations entres les entités, et en faisant le lien avec les foreign key/tables de jointure ("Un user peut avoir plusieurs adresses mais une adresse n'appartient qu'à un seul user, une clef étrangère user_id se trouvent donc du côté de l'adresse")
* Ne pas lister toutes les propriétés des entités, mais parler de celles qui sont intéressantes (Un user a une propriété role ? Dire le rôle par défaut et ses valeurs possibles et éventuellement dans quel cas il peut changer de rôle. Un produit a un stock ? Quand est-ce que cette valeur change. etc.)
* Si vous avez beaucoup d'entité et de relations, ptêt pas tout lister

### Structure de l'application
* Parler du modèle MVC, avec un petit schéma c'est encore mieux
* Parler du fait que l'appli est une application client-serveur avec API Rest d'un côté et framework js de l'autre
* Pourquoi pas un screen ou un schéma de l'organisation de vos dossiers

### Explication de code
* Prendre des extraits précis de code et pas un fichier entier avec trop de trucs
* :warning: Ne pas lire le code : "alors j'ai fait un if machin, puis un for let truc of bidule et dedans un new TrucTruc", ça, ça donne l'impression que vous savez pas ce que fait le bout de code (et si vous l'avez sélectionné et mis dans votre slide, vaut mieux que vous le compreniez)
* Plus que de faire de la lecture/du ligne par ligne, essayer autant que possible de traduire en français ce qui se passe (`let user = new User()` : "je commence par créer une instance de la classe user afin de...")
* Entrainez-vous sur ça, pasque c'est pas évident de parler de son code, mais c'est un skill important, même hors titre (et ça peut vous aider à mieux le comprendre à terme)

### Démo
* Préparer un scénario pour la démo et vous y tenir, vous pouvez même l'annoncer avant de faire la démo
* Exemple de scénario pour un site e-commerce, Passer une commande ce qui dans le détail comprend :
1. Afficher des produits
2. Sélectionner un produit et l'ajouter à son panier
3. Se connecter
4. Consulter et valider son panier
5. Valider la commande
6. Constater dans la liste de mes commandes en cours qu'une commande s'est rajoutée
* Préparer à l'avance les data à utiliser : vous savez ce que vous cherchez, vous savez les identifiants du user à utiliser, si vous avez un formulaire à remplir, vous l'avez déjà prérempli (avec des données crédibles) pour pas pas passer 5 minutes à remplir chaque champs avec des "kqsljf" ou "test"
* Ne surtout pas se ballader sans but précis dans l'application en commentant de manière désorganisée ce qui s'y trouve. Déjà c'est chiant, mais en plus c'est le meilleurs moyen de tomber sur des bugs ou des soucis
* L'intérêt de faire un scénario, c'est que du coup vous contrôlez complètement ce que vous allez montrer, donc même si tout tombe en ruine autour et que rien d'autre ne marche, si au moins la tranche que vous montrez est ok et maitrisée, alors ça passe complétement (mais en vrai, faites autant que possible que le trucs soit pas en ruine autour, au cas où)

### Conclusion
* Points de difficultés
* L'intérêt que vous y avez trouvé
* Ce qui pourrait être fait pour une V2
* Merci, question ?

###### tags: `Général` `Titre` `Présentation`