# Support de présentation type CDA
Construire un plan qui présente votre compréhension des principales étapes d'un projet informatique, leur enchaînement logique, le respect de ces étapes dans le cadre de votre chef-d'œuvre. Faire la démonstration qu'on sait comment traduire un besoin client (utilisateur) en programme informatique dans les "règles de l'art".

Le support de présentation est une **synthèse** du dossier projet, il n'est **pas exhaustif**. Cependant, si vous voulez, par exemple, mettre en avant le déploiement, vous pouvez. Le tout est de couvrir les compétences obligatoires listées dans le référentiel de certification et de **bien gérer son temps** de présentation. Le secret c'est l'entraînement !

Le chef-d'œuvre n'est pas un concours d'innovation, de start-up ! Ni un concours de nombre de fonctionnalités. Il faut chercher à couvrir les compétences du référentiel, et le faire bien. Autrement formulé, une application avec authentification des utilisateurs et les quatre opérations CRUD fait très bien le travail. Le tout est de faire ça bien, de la conception au déploiement en passant par l'implémentation et les tests.

## Les slides

### Expression des besoins, contexte
- Expliquer la problématique, une application pour qui et pour quoi, la solution envisagée, les limites du projet. Description des aspects fonctionnels. On peut s'appuyer sur des personae et autres techniques marketing, mood board, benchmarks...
- Objectifs de qualité, stratégie et plan de test, éco-conception, accessibilité, bonnes pratiques, sécurité, réglementation le cas échéant (penser à la CNIL/RGPD...), référencement

### Gestion de projet
- Démontrer qu'on sait identifier, organiser et prioriser des tâches. Choix d'une méthode de gestion de projet et un workflow adaptés à votre contexte. On s'appuie typiquement sur des captures d'écrans de l'outil de gestion utilisé pour illustrer
- C'est une section où vous pouvez également évoquer Git et GitHub comme outils collaboratifs, suivi de l'évolution du code, stratégie de branches

### Conception

#### Interfaces utilisateurs
- Zoning, wireframes, charte graphique, intégration statique de l'ensemble en HTML/CSS (possibilité d'utiliser Bootstrap ou équivalent), arborescence du site (comment un utilisateur peut passer d'un écran à l'autre)
- Prise en considération de l'adaptation des écrans aux périphériques (bureau, mobile, tablette) selon les besoins de l'application. Même s'il n'est pas justifié pour l'application d'être "responsive" il faut tout de même savoir de quoi ça parle et comment ça marche
- L'esthétique n'a que peu ou pas d'importance, il faut démontrer qu'on comprend l'intérêt des différentes étapes, qu'on sait respecter une charte graphique d'entreprise en l'intégrant
- Prendre un exemple significatif dans les slides, pas toutes les fonctionnalités. Toutes les maquettes doivent être dans le dossier projet cependant

#### Données (méthode MERISE, règles de normalisation, schémas E/A et relationnels)
- Modèles conceptuel et logique (relationnel) des données. Identification des entités métiers, leurs attributs et associations. Quelles données manipulent les utilisateurs et comment elles sont organisées en vue d'être stockées
- Je jury évalue la capacité d'abstraction du domaine métier, fonctionnel, et le respect des règles de la méthode pour passer d'une étape (modèle) à l'autre

#### Traitements, orienté objet (formalisme UML)
- Cas d'utilisation, diagramme de classes, diagramme de séquences avec scénario alternatif (typiquement une gestion d'erreur ou d'exception). Un seul diagramme de séquences (correspondant à un cas d'utilisation), même dans le dossier projet il n'est pas attendu d'avoir tous les diagrammes de séquences pour tous les cas d'utilisation
- Démontrer que les traitements répondent bien aux besoins des acteurs du système, expliquer comment votre programme fonctionne, les responsabilités des différents composants/objets, comment ils communiquent entre eux

#### Architecture
Pas de formalisme particulier mais démontrer sa compréhension d'une architecture découpée en couches logiques (présentation, métier, données), motivations, avantages, inconvénients.

### Stack technique
- Généralement illustrée par les logos (ou liste à puces) des principaux (pas tout) langages, frameworks et bibliothèques choisis
- Démontrer que le choix est pertinent par rapport à la conception et l'architecture multicouches (en quoi ça répond aux besoins)

### Implémentation, extraits de code
- Captures d'écrans ou copier-coller (dans des zones de texte) d'extraits de code significatifs de toutes les couches de l'application. Dans cette partie, le jury vérifie que c'est bien votre code, que vous le comprenez, que vous avez le vocabulaire. Il vérifie également la cohérence avec la conception
- Note sur la base de données relationnelle : mise en avant de la mise en place de la base de données avec des scripts SQL qui sont également la 3ème étape de la méthode MERISE, après les modèles conceptuels et logiques. Script qui insère des données "statiques" ou référentielles (compte administrateur, pays, catégories...) si jamais il n'y a pas encore la possibilité de le faire dynamiquement (par des fonctionnalités implémentées)

### Tests
- Démontrer qu'on a une culture générale sur les tests (niveaux et types), qu'on comprend leur importance et réalisation de quelques tests respectant la stratégie de test du projet
- Il ne s'agit pas de couvrir tous les niveaux et encore moins tous les types. Essayer d'avoir une stratégie qui permet de vérifier qu'une fonctionnalité fonctionne comme attendue (comme spécifiée), de bout en bout, incluant les cas d'erreurs
- Le minimum est de mettre en place des tests dits UAT, même manuels, avec un support qui décrit les scénarios (données en entrée, résultat attendu, résultat obtenu, plan d'action correctif). Rester synthétique dans la présentation orale, mais le dossier projet doit montrer que vos fonctionnalités sont toutes testées

### Veille sur la sécurité
- Faire une veille individuelle sur la sécurité en rapport avec votre projet, en montrer les résultats
- Cette veille conduit à vérifier et démontrer que votre projet n'est pas vulnérable au problème en question ou bien que vous avez mis en œuvre une solution pour palier au problème de sécurité
- Peut concerner n'importe quelle couche de l'application

### Démo
- Démo scénarisée, pas improvisée, d'une partie de l'application, une ou deux fonctionnalités significatives
- Sur les 40mn, la démo c'est de l'ordre de 2 ou max 3 minutes. Le jury vérifie que c'est effectivement implémenté, que ça marche, que vous connaissez votre application, et vous avez la satisfaction de montrer le résultat de tout votre travail !

### Conclusion
- Difficultés rencontrés, comment elles ont été surmontées, satisfactions
- Se projeter dans le métier de développeur, qu'est-ce que vous allez faire après

## Échanges, entretien avec le jury
- Le jury peut poser parfois des questions scolaires, genre définition d'un terme, d'un concept
- Principalement le jury challenge sur votre modèle de données, les règles de normalisation et l'orienté objet en s'appuyant sur vos diagrammes UML. **La conception (notamment back-end) est le sujet principal**. Il y a toujours plusieurs façons de faire, le jury vérifie que vous savez argumenter vos choix
- Écrire une requête SQL en se basant sur le modèle de données de l'application
- Il vérifie que vous comprenez ce que font les frameworks et bibliothèques pour vous, notamment dans la communication entre chaque couche. Il peut vous demander d'aller dans un de vos IDEs et vous poser une question sur une ligne de code
- Le jury peut vous demander d'aller dans l'application et vous faire naviguer pour vérifier certains fonctionnements (typiquement ce qu'on appelle la protection des routes, vérifier qu'un écran qui ne devrait pas être accessible, par certains utilisateurs, ne l'est effectivement pas)
- Échanges sur votre projet professionnel, votre vision du métier de développeur, comment pourrait évoluer votre chef d'œuvre s'il devait se poursuivre