Skip to content

CahierDesCharges

empesce edited this page Dec 2, 2020 · 20 revisions

Cahier des Charges

Index

  1. Présentation générale du projet
    1. Présentation des acteurs
    2. Nature de la prestation demandée
    3. Estimation des grandes étapes et dates butoirs
    4. Organisation de l'équipe et du travail
  2. Cahier des charges fonctionnel
    1. Fonctionnalités attendues
    2. Contraintes sur la réalisation projet
    3. Contraintes sur l'utilisation du produit
    4. Critères d'appréciation de la qualité du produit

Présentation générale du projet

Présentation des acteurs

Suite à l'appel d'offre de M. Laurent Provot*, les deux collaborateurs Romain Olivier et Augustin Laborie ont décidé de proposer une offre acceptée par l'initiateur. Pour la bonne réalisation du projet, l'équipe a du s'agrandir et rallier Emrick Pesce, Thomas Blanc ainsi que Yoann Periquoi.

Il est donc logique que M. Laurent Provot soit le maître d'ouvrage car il est à l'initiative de l'idée du projet sans pour autant faire parti de la production. Suite à la formation de l'équipe et de réunions préalable, nous avons décidé d'élire le chef de projet par vote. Le résultat fut l'élection de Romain Olivier. Tous les membres de l'équipe sont cependant hiérarchiquement équivalent. C'est pourquoi chacun d'eux font partie de la maîtrise d'oeuvre.

* Pour le bien de la réalisation du projet scolaire, cette situation est factice. La description de chacun des membres est disponible dans leurs pages personnelles.

Nature de la prestation demandée

Ce projet réside en la réalisation d'un logiciel permettant d'utiliser l'appareil LeapMotion pour lancer des scripts à partir de gestes prédéfinis qui seront alors reconnus par l'appareil.
Le LeapMotion est un capteur permettant de virtualiser nos mains. Cela nous permet ainsi de lancer un traitement prédéfini lorsqu'un certain mouvement est reconnu. Ce projet n'est pas une innovation puisque de nombreux autres logiciels sont déjà en circulation sur la plateforme de téléchargement d'application du LeapMotion (LeapMotion SDK). Cependant nous ne partons pas d'une base déjà existante pour réaliser notre propre logiciel, nous utilisons seulement la librairie fournie par les développeurs du LeapMotion.

Nous devrons livrer un logiciel fonctionnel et déployable avec lequel sera disponible une interaction complète via une interface graphique et une interface en ligne de commande (ou CLI) avec le contrôleur LeapMotion. Ces interactions nous permettrons alors de pouvoir lancer un script (suite de commandes) et ainsi de réaliser des tâches à partir d'un seul mouvement.

Celui-ci devra permettre à l'utilisateur de :

  • Gérer ses scripts (créer, modifier, lire, mettre à jour et supprimer les scripts et leurs gestes déclencheurs)
  • Initialiser ses scripts grâce à des mouvements
  • Gérer la connexion avec le LeapMotion
  • Avoir un retour visuel de ce que perçoit le LeapMotion
  • Lancer un script à tout moment grâce à un outil qui observe en permanence le flux vidéo et repère les gestes
  • Enregistrer son environnement sur une base de données distante
  • Récupérer son environnement depuis n'importe où grâce au serveur distant
  • S'authentifier pour accéder à son profil
  • Utiliser son propre profil en local avec une gestion "hors ligne"

Ces fonctionnalités sont observables dans le diagramme de cas d'utilisation accessible sur le wiki du projet.

Lors de ces interactions, on sera capable de rattacher des processus afin de se servir du LeapMotion comme un hub (voir GoogleHome / Alexa). Ce logiciel a plusieurs objectifs :

  • Une utilisation quotidienne pour quiconque possédant un LeapMotion
  • Une aide supplémentaire pour les personnes en situation d'handicap
  • Une solution innovante pour des interactions sans contact (respect des règles sanitaires)

Estimation des grandes étapes et dates butoirs

Image

Organisation de l'équipe et du travail

Ce projet se réalisera majoritairement en distanciel du fait de la crise sanitaire actuelle.
Aucune réunion ou meeting n'est donc possible en présentiel sur la première période de réalisation.

Pour la réalisation du projet, l'équipe de développement a opté pour une méthodologie inspirée de SCRUM (en version allégée).

Les outils de conceptions de l'équipe seront :

  • Communication: Discord / BBB / Teams
  • Version Control: Git/GitLab/GitKraken/CircleCI
  • Éditeur: IntelliJ IDEA, VSCode, Sublime Text, DBeaver
  • Matériel: Ordinateurs personnels (Windows/Linux), LeapMotion
  • Langage: Java, JavaFx, Spring(API), JavaScript(React),MarkDown
  • Design: Adobe XD, Balsamiq, Photoshop

Cahier des charges fonctionnel

Fonctionnalités attendues

Lors de ce projet, nous allons fournir différentes fonctionnalités :

graph TD
   app(Handy Hand) --> noy[1.Noyau]
   app --> grp[2. Interaction]
   app --> bdd[3. Base de Données]
   app --> doc[4. Documentation]
   bdd --> mouv[3.1 Mouvements]
   bdd -.-> scr[3.2 Scripts]
   bdd --> inf[3.3 Infos Utilisateur]
   noy --> api[1.1 Rest API]
   grp --> gr[2.1 Interface Graphique]
   grp --> cli[2.2 Interface en ligne de commande]
   doc --> conc[4.1 Diagrammes de conception]
Loading
Niveaux Description
Niveau initial HandyHand: Application reconnaissant des mouvements de mains et exécutant des scripts à partir de ceux-là
Niveau 1
1. Noyau: Responsable de toutes les interactions métiers avec le LeapMotion
2. Interaction: Responsable de l'Interaction Homme-Machine
3. Base de Données Responsable du stockage des données
4. Documentation Documentation détaillée de la structure de l'application et de ses composants
Niveau final
1.1 Rest API Permet la transition de données entre toutes les interfaces et le noyau sans réécriture unique
2.1 Interface Graphique Interface ergonomique permettant la configuration des interactions avec le LeapMotion
2.2 CLI Interface simplifiée permettant la configuration sur des outils sans interface graphique
3.1 Mouvements Collection de données représentants les mouvements compris par le noyau
3.2 Scripts Collection de scripts reliables à des interactions avec le LeapMotion
3.3 Infos Utilisateurs Collection d'informations données par l'utilisateur pour les interactions (Clé API, ...)
4.1 Diagrammes de Conception Description détaillée de l'architecture de l'application suivant les normes UML

Une description plus poussée de ces tâches peut être retrouvée dans la partie BackLogs de notre wiki.

Contraintes sur la réalisation du projet

Lors de la réalisation de ce projet, nous faisons face à différentes sortes de contraintes.

Nous pouvons relever les difficultés du travail en distanciel durant l'intégralité de la première période. Entre autre, on note l'utilisation de nos ordinateurs personnels comme outils principaux. La récupération des LeapMotion en situation de confinement. Les connexions internet instables et limitées de nos résidences. L'impossibilité de contact humain entre les collaborateurs mais aussi avec le maître d'ouvrage qui complexifie la communication et ralentit le processus de développement.

Nous faisons aussi face à des contraintes de temps, le projet ayant des dates butoirs à respecter. Nous devons également prendre en compte le temps de réalisation de projets scolaires parallèles et des cours universitaires.

Contraintes sur l'utilisation du produit

L'utilisation du produit requiert l'obtention d'un LeapMotion ainsi qu'un ordinateur quelconque (Windows/Linux/Raspberry) avec Java installé.

Avoir au minimum une main fonctionnelle avec 5 doigts.

L'appareil LeapMotion nécessite une petite "période d'adaptation" afin de comprendre la distance à laquelle il faut placer sa main, les gestes reconnus...

L'application nécessite la création de scripts et donc d'une connaissance poussée de l'informatique et d'un langage de programmation pour mettre au point un traitement efficace.

Critères d'appréciation de la qualité du produit

L'appréciation du produit se fera à travers différents vecteurs. Notamment les retours utilisateurs, l'ergonomie, la précision de détection, la rapidité d'exécution.

Les retours utilisateurs se feront tout d'abord via le maître d'ouvrage qui donnera alors son retour lors de démonstrations effectuées dans le cadre de fin de "sprint". Tous les retours seront alors pris en compte pour développer la suite.

L'ergonomie est pour nous un point très important car nous voulons rendre cette application accessible à tous et plus particulièrement aux personnes en situation d'handicap. Celle-ci pourra alors contenir des fonctionnalités comme un mode de contraste élevé ou bien la lecture des textes survolés. Elle sera aussi mise en valeur de par l'organisation de l'interface Homme-Machine mais également par une mobilité omniprésente permettant d'accéder à l'application facilement depuis n'importe où.

La précision de détection sera testée grâce à des batteries de tests permettant définir le nombre de fois qu'un mouvement est repéré en fonction du nombre d'essais. De plus on dénombre plusieurs difficultés de reconnaissance pour certains mouvements, c'est pourquoi l'acceptation de la précision pour un mouvement simple comme un doigt levé sera plus stricte que celle pour un cœur formé avec les mains.

La rapidité d'exécution est aussi un point important dans l'exécution de l'application. Elle devra être capable de se démarrer en moins de 10 secondes. La récupération de l'environnement utilisateur devra elle aussi être rapide via un enchaînement de requêtes efficaces c'est-à-dire moins de 3 secondes et idem pour la sauvegarde de l'environnement. Pour finir, l'exécution de scripts lors de la reconnaissance d'un mouvement connu devra être faite en moins de 3 secondes elle aussi.

Pour résumer, nous cherchons à rendre cette application aussi accessible qu’efficace.