- À propos
- Vue d’ensemble
- Informations générales
- Matériel et logiciel à disposition
- Descriptif du projet
- Livrables
- Points techniques évalués spécifiques au projet
- Conseils
- Acceptation du cahier des charges
«Les Bons Comptes Font Les Bons Amis» est un exercice de programmation destiné aux apprenti·e·s informaticien·ne·s CFC en voie développement d’applications. Il est fait pour se dérouler sous forme de Travail pratique individuel (TPI), dont le cadre est fixé par l’article 20 de l’Ordonnance du SEFRI sur la formation professionnelle initiale et l’évaluation faite selon les critères d’évaluation ICT, détaillés dans le document fourni par iCQ-VD.
Les sources de ce document se trouvent sur https://github.com/ponsfrilus/kata-lbcflba.
Contributions, remarques et commentaires bienvenues via https://github.com/ponsfrilus/kata-lbcflba/issues.
Le but de ce travail est de développer une application permettant de gérer les dépenses dans un groupe d’amis, par exemple pour une soirée, un voyage ou une sortie. En créant une “ardoise” virtuelle, les utilisateurs peuvent entrer leurs frais respectifs et le système permet de facilement résumer le remboursement d’un utilisateur aux autres.
Le projet est nommé «Les Bons Comptes Font Les Bons Amis», abrégé LBCFLBA pour la suite.
Le Kata LBCFLBA est prévu pour être réalisé en une semaine (40 heures), sous la forme d’un mini-TPI ou TPI blanc. Il est néanmoins recommandé d’être flexible et d'adapter, en fonction de la personne, la durée prévue pour la réalisation.
La répartition du temps suggérée est la suivante :
| Horaire | Heures | Jours | |
|---|---|---|---|
| Analyse | 10% | 04:00 | ½ |
| Implémentation | 40% | 20:00 | 2½ |
| Tests | 10% | 04:00 | ½ |
| Documentation | 30% | 12:00 | 1½ |
| Total | 100% | 40:00 | 5 |
L’horaire est de 8 heures par jour :
| Horaire | Pause | Durée | |
|---|---|---|---|
| Matin | 08:40 - 13:00 | 20 minutes | 4h00 |
| Après-midi | 14:00 - 18:15 | 15 minutes | 4h00 |
| Total | 8h00 |
La réalisation de ce travail nécessite uniquement un laptop et un accès à Internet. L’utilisation de logiciels libres est fortement recommandée.
Le but de ce projet est de développer l’application LBCFLBA, une ardoise virtuelle permettant de facilement tracer et répartir les coûts entre les participants d’un événement.
Ce cahier des charges ne précise aucune technologie pour la réalisation de cette application. Il est attendu de la part du·de la candidat·e une réfléxion sur la meilleure manière de livrer une telle application dans le temps imparti. Il est donc présumé ici que le candidat choisira une solution dans sa zone de confort et fournira, à l’issue du mini-TPI, un site Internet ou une application mobile, voire les deux en même temps.
Les maquettes des écrans proposées dans ce document sont présentées uniquement pour illustrer une possible réalisation du projet. Elles permettent de se mettre dans la peau des utilisateurs·trices et de s'imaginer une version de la solution. Elles ne font pas office de référence pour la création de l’application.
Alice, Bob, Carole et David ont prévu une sortie au Montreux Jazz Festival pour fêter l’anniversaire de David. Pour cette sortie, tous les frais sont pris en charge par Alice, Bob et Carole en guise de cadeau à David.
Alice prend les billets de train Lausanne Montreux aller retour :
4 x 2 x 6.50 = 52.-
Bob commande les billets d’accès au festival pour la soirée :
4 x 88 = 352.-
Il en profite pour acheter l’affiche de la 56e édtion faite par Camille
Walala, il l’offrira à David en souvenir de la soirée :
69.-
Une fois sur place, Carole achète des crêpes et des boissons (4 crèpes salées, 2
sucrèes, 4 boissons) :
106.-
Pendant le concert, Carole va au bar et ramène des bières pour tout le monde :
4 x 6 = 24.-
Plus tard, Alice va chercher des verres d’eau gazeuse :
4 x 4.5 = 18.-
Le montant de la soirée s’élève à 620.-. Sachant que David ne doit rien payer (les frais lui sont offerts pour son anniversaire), comment partager les frais entre Alice, Bob et Carole ?
➥ Pour effacer toutes les ardoises, Alice et Carole sont débitrices de Bob de respectivement 137.- et 77.- (Bob est créancier pour un montant de 214.-).
La practicité de l’application est le mot d’ordre.
Il y a deux cas d’emplois :
- L’utilisateur utilise l’application pour créer une nouvelle ardoise ;
- L’utilisateur est invité à rejoindre une ardoise existante.
Ces deux cas d’emplois sont expliqués plus en détails dans la description des différents écrans ci-dessous.
L’écran d’accueil de l’application doit permettre à l’utilisateur de rapidement comprendre à quoi l’application sert, de créer une ardoise et de naviguer entre les différents écrans.
Il se compose de :
- Un titre
- Un texte sommaire (une accroche)
- Un bouton pour créer une ardoise
- Un lien vers l’aide/FAQ
- Un lien vers à propos
{ width=252px }
Lorsque l’utilisateur veut créer une nouvelle ardoise, on lui demande :
- Le titre de l’ardoise (obligatoire)
- La description de l’ardoise (facultative)
- Une date de fin (facultative)
La confirmation de la création de l’ardoise gènère un hash unique permettant au créateur de l’ardoise de la partager.
{ width=252px }
Lorsqu’un utilisateur accède à une ardoise avec un lien, il doit d’abord s’identifier : il peut soit cliquer sur le nom d’un participant existant soit créer un nouveau participant.
{ width=252px }
Il peut ensuite intéragir avec tous les éléments avec l’autorité de la personne qu’il a séléctionnée :
- Consulter les dépenses existantes
- Ajouter une nouvelle dépense à l’ardoise
- Modifier une dépense existante
- Supprimer une dépense
Cet écran affiche également une information permettant de voir qui devrait être la prochaine personne a payer une dépense (dans le but de tendre vers une équité des dépenses).
?? Drop down personne ??
Un bouton pour accéder au détail du rapport est disponible.
{ width=252px }
Cet écran propose un état des comptes et comment résoudre l’ardoise (qui doit combien à qui). Il est fait de manière intelligible* et facilement partageable.
L’écran d’aide explique comment utiliser l’application et liste les questions posées fréquement (FAQ). Un lien vers les issues du dépôt est proposé aux utilisateurs.
L’écran à propos est une impressum qui explique qui, quand, quoi, comment, affiche un numéro de version et un lien vers les sources. On y fait appel aux contributeurs.
La première tâche du·de la candidat·e est de réaliser sa planification initial, qu'iel enverra (au format PDF) aux intéressé·e·s. Cette planification initiale détaille les tâches à accomplir durant le projet. Le niveau de granularité du découpage doit être adapté au projet.
Tout au long du projet, le·la candidat·e mettra à jour la planification rééle.
En fin de projet, le·la candidat·e veillera a ajouter les planifications initiale et rééle dans son rapport, et prendra le soin d’en commenter les différences.
Les intéressé·e·s (experts, chef de projet) doivent avoir accès au code du candidat en tout temps. Ce dernier veillera donc à transmettre, lors de toutes ses communications, le lien vers la dernière version de son code.
Un canevas de dossier de projet est à disposition du·de la candidat·e.
Le rapport prête une attention particulière à détailler tous les points techniques évalués spécifiques au projet, prouvant que l’élément a été traité de manière professionnelle par le·la candidat·e.
Les termes techniques et les acronymes utilisés dans le rapport sont référencés dans un glossaire figurant dans le rapport.
Les choix technologiques sont justifiés dans le rapport. Les outils et les technologies utilisées sont l’objet de descriptions explicatives dans le rapport.
Le candidat démontre sa compréhension du système en fournissant un schéma d’architecture dont la description détaille l’intéraction entre les différents systèmes.
Le document doit évoluer chaque jour. Il sera envoyé dans l’état aux intéressé·e·s deux fois par semaine, au format PDF. Dans le cas d’un mini-TPI, le rapport est envoyé chaque jour.
Le rapport contient tous les documents nécessaires à la compréhension du déroulement du projet en annexes. Cahier des charges, planifications, journal de travail, résumé du rapport TPI, etc. doivent être annexés au document.
Le journal de travail doit permettre de retracer les activités du·de la candidat·e tout au long du déroulement du projet. Durée des tâches, PV des discussions, problèmes rencontrés, choix, solutions, liens vers la documentation, les références, sources d’informations, aide extérieure, heures supplémentaires, etc. doivent être consignés dans ce document (c.f. critères d’évaluation B2).
Le journal de travail est présent dans le dossier de projet, en annexe au rapport.
Le document doit évoluer chaque jour. Il sera envoyé dans l’état aux intéressé·e·s deux fois par semaine, au format PDF. Dans le cas d’un mini-TPI, le journal de travail est envoyé chaque jour.
Le·la candidat·e communique l’adresse de son dépôt Git aux intéressé·e·s et le
maintient à jour quotidiennement (plusieurs commits par jour). Le dépôt est
agrémenté d’un fichier README.md au format MarkDown, qui explique
l’utilisation du projet et sa mise en œuvre. (Voir aussi l’objectif «simplicité
des instructions de mise en œuvre», ci-dessous). Le lien vers le dépôt est
présent dans la documentation.
La grille d’évaluation définit les critères généraux selon lesquels le travail du candidat·e sera évalué (documentation, journal de travail, respect des normes, qualité, …).
En plus de cela, le travail sera évalué sur les 7 points spécifiques suivants (correspondant aux critères d’évaluation A14 à A20) :
-
La qualité du repository Git : messages de commits explicites et lisibles, permettant de retracer l’évolution du code (plusieurs commits par jour, création de branches de fonctionnalités), fichier
README.mdprésentant le projet et son déploiement. -
Un code exempt de sections copiées/modifiées (principe DRY: Don’t Repeat Yourself) et respectant le style de programmation des langages utilisés.
-
La simplicité des instructions de mise en œuvre, qui permettent aux intéressé·e·s d’essayer le projet sur leur propre équipement au fur et à mesure de sa progression.
Idéalement, les instructions se limitent à deux étapes (git cloneetdocker-compose up). -
Les différentes méthodes HTTP sont implémentées à bon escient en fonction de l’action réalisée sur la ressource indiquée. Les codes de réponse HTTP utilisés permettent aux clients d’avoir une information sur le resultat de leurs requêtes.
-
Le front-end est soigné, la liste des mangas paginée, triable et la possibilité de faire une recherche dans la table est présente.
-
Le rapport démontre que le·la candidat·e a étudié le modèle des données : un diagramme entité-association (ERD) est présent dans le rapport. Le·la candidat·e décrit et critique le diagramme et les différentes tables.
-
L’utilisateur·trice a accès à une page de documentation de l’API, qui explique les types de données, les valeurs de retour, les différentes possibilités d’interactions avec l’API. Le respect de OAS et l’utilisation des fonctions de documentation de Swagger sont nécessaires pour obtenir le score maximal sur ce point.
Le rapport, le journal de travail et le dépôt Git doivent être mis à jour en continu pour rendre compte des accomplissements à chaque étape ci-dessus.
Aucune «hypothèque» de temps de travail péjorant la documentation ni le code, ne seront tolérées.
| Lu et approuvé le | Signature | |||
|---|---|---|---|---|
| \vphantom | ||||
| Candidat·e | _________________ | _________________ | ||
| \vphantom | ||||
| Expert·e n°1 | _________________ | _________________ | ||
| \vphantom | ||||
| Expert·e n°2 | _________________ | _________________ | ||
| \vphantom | ||||
| Chef·fe de projet | _________________ | _________________ | ||
| \vphantom |