Skip to content

THEDRE Cahier des charges

Mandran Nadine edited this page Jul 26, 2017 · 43 revisions

Cahier des charges pour le projet de M1 - Solène, Emeric, Alexandre et Nadine

Objectifs

La finalité de cette partie du projet sera la réalisation d'une application web, intégrée au projet SAKURA, servant à la création et au suivi de projet, ou d'étude, initié par un chercheur.

Ainsi, les chercheurs, actuels et futurs, pourront utiliser cette application pour la création de projet, ou d'étude, dans le cadre de leur recherche en employant la méthode THEDRE, accompagné de méthodologue et encadré, pour les doctorant, par un directeur de thèse. Cette méthode suit les pratiques du chercheur, de la formulation de l'objectif de la recherche au choix de publication ou d'approfondissement de la recherche si les résultats obtenus ne sont pas suffisants ou incohérents.

L'application sera donc prévue pour différents utilisateurs, à savoir, les chercheurs, les méthodologues, les directeurs de thèse et les administrateurs. Chaque utilisateur pourra faire différentes actions en fonction de son ou ses rôles, car il faut savoir qu'un utilisateur peut cumuler différents rôles. Un chercheur pourrait être méthodologue sur un autre projet ou un méthodologue pourrait avoir le rôle de directeur de thèse pour un doctorant.

Les chercheurs n'utiliseront que le front-end et devront pouvoir créer, modifier, supprimer des protocoles expérimentaux, exporter le protocole en format RTF ou l'imprimer au format PDF, accéder au données générique du protocole ainsi qu'à ses autres protocoles existant. Gérer les collaborateurs participant à l'étude, ajouter ou retirer des collaborateurs, si le chercheur est doctorant, il doit obligatoirement ajouter un directeur de thèse, et leur donner des accès en fonction des besoins. Le chercheur pourra décrire les données expérimentales, télécharger les données quels que soient leurs formats (audio, vidéo, texte, ...).

Les méthodologues, eux, seront ceux qui utilise le back-end de l'application. Ils devront avoir la possibilité de créer et modifier les guides et les règles de décisions, documenter et modifier les préconisations liées aux méthodes, accéder et annoter les informations rentrées par le chercheur et enfin pourvoir demander l'accès aux protocoles et aux données au chercheur qui est à l'origine du projet ou de l'étude.

Les directeurs de thèse, quant à lui, ne pourra qu'accéder et annoter les informations renseignées par le chercheur et pourra demander l'accès aux protocoles et aux données, comme pour le méthodologue. Enfin l'administrateur, lui pourra accéder à tout car il sera surtout présent pour empêcher les problèmes d'accès ou de droit des autres utilisateurs.

=> méthodologue=> gérer en back end

  • créer les guides
  • modifier les guides
  • créer les règles décisions
  • modifier les règles de décisions
  • documenter les préconisations liées aux méthodes
  • pouvoir modifier les préconisations
  • accéder aux informations rentrées par le chercheur
  • annoter les informations rentrées par le chercheur
  • demander l'accès aux protocoles => envoi d'un mail au propriétaire
  • demander l'accès aux données => envoi d'un mail au propriétaire

=> chercheur => front end

  • créer le protocole expérimental (propriétaire)
  • dans le cas des doctorants => envoi d'un mail au directeur de thèse
  • modifier le protocole expérimental
  • supprimer le protocole expérimental
  • exporter le protocole expérimental => RTF
  • imprimer le protocole expérimental => pdf
  • partager le protocole =:> entrer une adresse mail
  • partager les données
  • gérer les collaborateurs (ajouter, enlever, ... )
  • décrire les données
  • télécharger les données expérimentales
  • télécharger des audio et des vidéos
  • avoir accès aux protocoles existants / les siens => liste
  • Avoir accès aux données génériques du protocole

=> directeur de thèse => front end

  • accéder aux informations rentrées par le chercheur
  • annoter les informations rentrées par le chercheur
  • demander l'accès aux protocoles => envoi d'un mail au propriétaire
  • demander l'accès aux données => envoi d'un mail au propriétaire

=> Administrateur : Accès à tout.

Techniques

Le projet étant l'application web, nous pouvons distinguer trois parties distinctes, l'application du côté serveur, l'application du côté client et enfin la base de données. C'est trois parties utiliseront une technologie différente :

  • L'application du côté serveur est réalisée en Python. Cette partie de l'application ne sera de notre ressort.
  • La base de données est réalisée avec PostgreSQL.
  • L'application du côté client est réalisée en JavaScript. C'est de cette partie dont nous allons nous occuper.

Fonctionnalités génériques

  • gérer le Versionning guides
  • gérer le versionning des données d'un formulaire
  • gérer le versionning des données expérimentales

Tâches

  • créer la bd à partir des guides

  • créer la bd pour gérer le versionning

    • Création de 2 bases de données par étape : une pour stocker les guides et leurs versions, et une autre pour stocker les données. La base des données évoluera au fur et à mesure des nouvelles questions des guides. Si des questions sont supprimées, les requêtes changeront, mais il n'y aura pas de données supprimées.
    • OU
    • Création d' une base de donnée par étape et par version de guide. Ce modèle serait probablement plus compliqué à gérer mais a l'avantage de ne pas pouvoir avoir de champ nul. Aucune base de donnée ne serait supprimée pour garder un archivage.
  • organiser les droits d'accès => selon les utilisateurs méthodologue/chercheur/directeur de thèse

  • organiser la gestion des collaborateurs

You can’t perform that action at this time.