Introduction
Le logiciel Tiré-à-part est un outil de référencement et d'indexation des publications scientifiques. Il permet 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.
Dans le souci de constituer une archive institutionnelle par la mise en œuvre 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. De ce fait, la migration éventuelle vers un progiciel de gestion des publications existant 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 en ce qui concerne 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.
*Directs
Chercheurs Le logiciel permet aux chercheurs de publier des articles, de partager des articles non publiés et de consulter des rapports d'activité en fonction des différentes équipes de recherche.
Responsable d'équipe Le responsable d'équipe, quant à lui, peut se servir de l'outil pour rester informé des publications de son équipe en temps réel à l'aide d'un flux RSS par exemple. Il peut également accéder au tableau de bord recensant toutes les statistiques de son équipe sur les cinq dernières années, gérer les catégories de publications de son équipe ainsi que les bases d'indexation bibliographiques.
*Indirects
Bien que n'étant pas directement concernés par le logiciel Tiré-à-part, le directeur du système d'information et le service commun de la documentation peuvent être perçus comme des utilisateurs indirects de l'outil.
Directeur du système d'information Il pourrait être concerné par les services Webs offerts par le logiciel et lui permettant d'intégrer ces données avec d'autres applications (interopérabilité).
Le service commun de la documentation Ce service est particulièrement concerné par le service d'archive ouverte et de référencement scientifique afin de le mettre à disposition des professeurs, étudiants et thésards. Ce service pourra également être utilisé par d'autres institutions (universités et pôles de recherche) après avoir accéder à la base de données nationale HAL.
Les 24 étudiants présents dans l'UV sont tous responsables qualité et non développeurs. Il n'y a pas de hiérarchie, chacun est donc responsable de la qualité du projet dans son ensemble et à niveau équivalent.
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... Ce dialogue avec les futurs utilisateurs et les personnes indirectement concernées permet de déduire les fonctionnalités que l'application devra implémenter.
Le fait que 24 personnes soient affectées sur le même projet nécessite une organisation rigoureuse du travail. Dans cette optique, nous avons utilisé github.com, une plateforme en ligne destinée au développement de projets informatiques, proposant les outils suivants :
- Gestionnaire de révisions "git", permettant à de nombreux collaborateurs de travailler en parallèle sur le même projet
- Outil de discussions ("issues") où toutes les informations sont centralisées à l'écrit : fonctionnalités à développer, erreurs à corriger, rapports d'avancement...
- Des outils de statistiques pour les développeurs
- Un Wiki pouvant être utilisé pour écrire en équipe la documentation de la future application
Dans notre méthode nous entamons l'écriture du manuel d'utilisation très tôt dans la chronologie de développement. Commencer par écrire le manuel d'une application qui n'est pas encore programmée peut paraître paradoxal, mais c'est en fait un bon moyen de cerner correctement toutes les fonctionnalités et ce à quoi elles devront ressembler une fois le produit terminé.
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 chaque lecteur puisse facilement trouver les sections qui l'intéressent. Ces points de vue sont ensuite divisés en différentes tâches que ces acteurs seront amenés à faire avec l'application, qui sont ensuite décrites en différents scénarios.
Les scénarios sont des mises en situation lors desquelles nous nous mettons à la place de l'utilisateur manipulant l'application finale. Il faut non seulement décrire les actions nécessaires pour remplir une tâche donnée, comme dans tout manuel d'utilisation, mais surtout bien comprendre le contexte et les raisons pour lesquelles l'utilisateur a besoin de cet outil. Afin de faciliter la compréhension des différentes choses à faire, nous mettons l'accent sur les illustrations avec les maquettes.
Nous avons décidé d'utiliser le logiciel Balsamiq pour créer les maquettes à intégrer 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. Les maquettes possèdent le plus souvent des notes afin que les illustrations contiennent le plus d'informations possible, ce qui rend le manuel plus facile à lire.
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 etc), 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 ?
- Suivre au plus près les scénarios que nous avons écrits
- 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)
- 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.