Introduction

Sujet

Qu'est ce que c'est : Tiré-à-part?

Le logiciel Tiré-à-part est un outil de référencement et d'indexation des publications scientifiques. Il permet également de visualiser et d'évaluer l'état d'avancement de projets au sein d'une équipe de recherche. Il est principalement destiné aux établissements d'enseignement supérieur possédant des équipes de recherche tout en conservant l'ensemble du patrimoine numérique d'un établissement.

Pourquoi avoir développé le logiciel Tiré-à-part plutôt que d'utiliser un progiciel existant?

Dans le souci de constituer une archive institutionnelle par la mise en oeuvre d'un outil capable d'utiliser un modèle de données à la fois simple et fiable, le besoin de développer un logiciel tel que Tiré-à-part s'est exprimé tout naturellement. Utiliser un progiciel déjà existant aurait été une tâche lourde et fastidieuse dans la mesure où il aurait fallu le paramétrer afin qu'il corresponde au mieux aux besoins actuels des utilisateurs. Toutefois, l'un des avantages de Tiré-à-part est la facilité d'import et d'export des données et la migration éventuelle vers un progiciel de gestion des publications n'en sera que plus facile. Par ailleurs, la majorité des progiciels existants tel que ORI-OAI ne permettent pas de prendre en compte les attentes de tous nos utilisateurs notamment la gestion des contrats de partenariat avec des entreprises. Il en existe également qui ne possèdent pas des liens vers des bases de référencement nationales.

Quels sont ses utilisateurs?

*Directs

Chercheurs

Responsable d'équipe

*Indirects

Directeur du système d'information

Le service commun de la documentation

référencement

Méthode

Entretiens préalables avec les acteurs impliqués

Nous avons réalisé des entretiens afin de cerner l'état actuel des aspects qui concernent notre projet : le fonctionnement du circuit des publications de la recherche, les problèmes de l'ancienne application, les attentes...

Optique qualité

Les 24 étudiants présents dans l'UV sont tous responsables qualité et non développeurs. Il n'y a pas de hiérarchie, donc chacun est responsable de la qualité du projet dans son ensemble et à niveau équivalent.

Travail sur une plateforme de développement en ligne

Le fait que 24 personnes soient affectées sur le même projet implique qu'il faut organiser le travail correctement, dans cette optique nous avons utilisé Github.

Les "issues" permettent de regrouper au même endroit les différentes composantes du projet (améliorations à apporter, problèmes à résoudre, ajout de nouveautés...)

Écriture du manuel

Commencer par écrire le manuel d'utilisation pour une application qui n'est pas encore programmée peut paraître paradoxal, mais c'est un bon moyen de cerner toutes les fonctionnalités vers lesquelles le produit final devra converger.

Rôles

Nous avons décidé de répartir le manuel selon trois points de vue différents (Chercheur, Chef d'équipe et Interopérabilité) afin que chacun puisse facilement trouver les sections qui l'intéressent.

Scénarios

Afin de rester au plus près de l'utilisateur final, nous avons envisagé les différentes fonctionnalités selon son point de vue : quels sont ses besoins, quelles sont les tâches qu'il devra accomplir, pour quelles raisons etc. Le meilleur moyen de comprendre ces données est d'envisager l'utilisation de l'application selon une approche scénarisée.

Maquettes

Nous avons décidé d'utiliser un logiciel (Balsamiq) pour créer des maquettes que nous avons ensuite intégrées dans le manuel. A terme, ces images seront remplacées par de véritables captures d'écran de l'application finie, mais le manuel restera sensiblement le même qu'aujourd'hui.

Réalisation de tests automatisés

Les tests sont des scripts exécutés par un navigateur web et écrits sous forme de séquences (remplir un champ puis cocher une case puis cliquer sur un bouton puis...) ; ils permettent de manipuler l'application pendant son développement dans le but de vérifier que les fonctionnalités existantes fonctionnent, mais aussi de prévoir les fonctionnalités à venir.

Ainsi, en se basant sur les scénarios, nous avons programmé des tests de validation chargés de manipuler des éléments d'interface qui n'existent pas encore. Quel est l'intérêt ?

1. Suivre au plus près les scénarios que nous avons écrits
2. Répartir les tâches entre les concepteurs et les développeurs (le concepteur crée un test dans lequel il y a des éléments d'interface que le développeur va devoir programmer)
3. Au début les tests de validation échouent, mais une fois que le code a avancé et que les tests réussissent, ils deviennent des tests de "non-régression", c'est-à-dire qu'on les conserve et qu'on les relance à chaque nouvelle version de l'application pour vérifier qu'aucun mécanisme n'a été modifié par accident, provoquant ainsi la panne d'un dispositif qui fonctionnait très bien à la version précédente.