ECOM-1F0 1819 BTB

<<<< Retour vers la page ECOM 2018-2019

= Description du projet = Le chauffage individuel au bois non performant est une des causes majeures de pics de pollution de la région de Grenoble en période hivernale. Celui-ci est du à des émissions de particules dues à une mauvaise combustion venant d'appareils anciens, d'un défaut d'entretien ou de bois trop humide. Afin de lutter contre ce phénomène, FIBOIS AURA, Grenoble Alpes Métropole et le PNR du Vercors ont décidé de mettre en place une plateforme afin d'encourager de manière innovante les consommateurs à se tourner vers des professionnels en capacité de leur fournir un produit de qualité, sec. L'objectif est donc de regrouper la demande de bois en bûche des particuliers et de l'orienter vers des professionnels en capacité de livrer du combustible de qualité.

C'est dans cette démarche qu'ont été contactés 5 étudiants de 1F05 à Polytech Grenoble afin de mettre en place cette plateforme dans le cadre de leur enseignement portant sur le e-commerce.

Ce projet consiste dans le développement d'un prototype d'application ayant pour fonction la prise de commande en ligne par des consommateurs, le groupage des commandes par secteurs géographiques, le choix de fournisseurs professionnels, l'optimisation logistique pour la livraison et enfin des propositions de services associés.


 * Scénarios d'usages livrés par le client en début de projet.

= L'équipe et leurs rôles =

= Gestion d'équipe et de projet = Ayant un délai court et une équipe peu nombreuse, nous avons adopté la méthode Scrum pour la gestion du projet.

En tant que chef de projet, Léo VALETTE a joué le rôle de Product Owner, et Enzo MOLION a été désigné Scrum Master.

Dans le cadre de cette méthode ont été mis en place des Sprints de 3 semaines et des "daily meetings" hebdomadaires. Il a été décidé d'utiliser le site web de gestion de tableau kanban Trello.

L'équipe a ensuite été divisée en deux pôles : frontend et backend. Ce découpage a été fait de manière à séparer les binômes historiques. De plus, Léo VALETTE a été attribué au backend mais réalise également l'interface avec le frontend et a ensuite été pour cette raison désigné responsable de l'intégration continue.

=Technologies=
 * Backend
 * JHipster
 * Maven
 * Frontend
 * Angular
 * Angular Material
 * DevOps
 * GitLab CI/CD
 * JHipster Registry
 * Gestion de projet
 * Pomodoro (abandonné avant mise en place)

Outils

 * Gitlab : pour le dépôt, pour la documentation, l'intégration en continu. Notre dépôt ici
 * Trello : pour la gestion des sprints et des user stories. Notre Trello ici
 * Suite Google Drive : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)

= Livrables =

Journal

 * Journal de l'équipe
 * Journal Amina BOUCHERIMA
 * Journal Zoran CHANET
 * Journal Najwa EZ-ZINE
 * Journal Enzo MOLION
 * Journal Léo VALETTE

Slides

 * [[Media:BTB_Audit1.pdf | Slides Audit 1 (PDF)]]
 * [[Media:BTB_Audit2.pdf | Slides Audit 2 (PDF)]]

Dossier de conception système
[[Media:ECOM_BTB_DCS.pdf |Dossier de conception système]]

Analyse des scénarios clients

 * Scénarios d'usages livrés par le client en début de projet.
 * [[Media:BTB_Liste_des_fonctionnalités.pdf | Liste des fonctionnalités ]] interprétée des scénarios.
 * [[Media:BTB_User_stories.pdf | User stories ]]

SRS
SRS

Dépôt Git
Dépôt GitLab

Application en ligne
website

API OpenAPI

Les heuristiques de NIELSEN
Voici les commentaires que nous pouvons faire pour analyser l'IHM de notre site selon les 10 heuristiques de Nielsen


 * Visibilité de l'état du système

Le système devrait toujours tenir les utilisateurs informés de ce qui se passe, grâce à une rétroaction appropriée dans un délai raisonnable.


 * Correspondance entre le système et le monde réel

Le système devrait parler la langue de l'utilisateur, avec des mots, des phrases et des concepts familiers à l'utilisateur, plutôt que des termes orientés système. Suivez les conventions du monde réel, en faisant apparaître les informations dans un ordre naturel et logique.


 * Contrôle et liberté de l'utilisateur

Les utilisateurs choisissent souvent les fonctions du système par erreur et ont besoin d'une "sortie de secours" clairement marquée pour quitter l'état non désiré sans avoir à passer par un dialogue prolongé. Support annuler et refaire.


 * Cohérence et normes

Les utilisateurs ne devraient pas avoir à se demander si des mots, des situations ou des actions différents signifient la même chose. Suivre les conventions de la plate-forme.


 * Prévention des erreurs

Encore mieux qu'un bon message d'erreur est une conception soignée qui empêche qu'un problème ne se produise en premier lieu. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant qu'ils ne s'engagent dans l'action.


 * Reconnaissance plutôt que rappel

Minimisez la charge mémoire de l'utilisateur en rendant visibles les objets, les actions et les options. L'utilisateur ne devrait pas avoir à se souvenir des informations d'une partie du dialogue à l'autre. Les instructions d'utilisation du système doivent être visibles ou facilement récupérables chaque fois que cela est approprié.


 * Flexibilité et efficacité d'utilisation

Les accélérateurs - invisibles pour l'utilisateur novice - peuvent souvent accélérer l'interaction pour l'utilisateur expert, de sorte que le système peut répondre à la fois aux besoins des utilisateurs inexpérimentés et expérimentés. Permettre aux utilisateurs de personnaliser les actions fréquentes.


 * Design esthétique et minimaliste

Les dialogues ne doivent pas contenir d'informations non pertinentes ou rarement nécessaires. Chaque unité d'information supplémentaire dans un dialogue entre en concurrence avec les unités d'information pertinentes et diminue leur visibilité relative.


 * Aider les utilisateurs à reconnaître, diagnostiquer et récupérer les erreurs.

Les messages d'erreur doivent être rédigés dans un langage simple (pas de codes), indiquer précisément le problème et proposer une solution constructive.


 * Aide et documentation

Même s'il est préférable que le système puisse être utilisé sans documentation, il peut être nécessaire de fournir de l'aide et de la documentation. Ces informations doivent être faciles à rechercher, axées sur la tâche de l'utilisateur, énumérer les mesures concrètes à prendre et ne pas être trop volumineuses.

Evaluation qualité du projet
Rapports SonarQube

Nombre d'heures travaillées
[[Media:ECOM_BTB_Heures_travaillees.pdf|Nombre d'heures travaillées]]

Evaluation économique du projet
Afin de procéder à l'analyse économique de notre projet, nous avons calculé son nombre de lignes de code (dans src, webpack et dans nos fichiers de configuration) qui est de 35721.

Via cette calculatrice, nous avons estimé les salaires des membres de l'équipe. En considérant que nous sommes ingénieurs fullstack, cela revient à 2950$ par mois et par personne.



Evaluation de la cybersécurité du projet (option)

 * [[Media:ECOM-1FO_1819_BTB_RGPD_Report.pdf]] (1 page de type checklist)

Evaluation des performances (option)

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)

Gestion des risques (option)

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]

Slides de présentation conception

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]

Slides de présentation finale

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]

Auto-évaluation

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]

Slides de présentation client

 * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]