Synthèse de l'étude "Pratiques de développement - ForgeESR"

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 22/10/10
  • Correction mineure : 30/07/13
Fiche archivée
Fiche archivée en accord avec son auteur, les résultats de l'enquête étant obsolètes aujourd'hui.
Mots-clés

Synthèse de l'étude "Pratiques de développement - ForgeESR"

Cette fiche n'est plus à jour. Elle a été archivée pour la raison exposée ci-contre.

Préambule

Le projet PLUME, le groupe Calcul et le réseau DevLog travaillent sur un projet visant à réaliser une étude prospective sur l'opportunité de proposer à la communauté Enseignement Supérieur - Recherche des solutions adaptées pour l'hébergement des développements des laboratoires de recherche.

Ce projet est décrit ici: http://www.projet-plume.org/ressource/projet-de-forge-ens-sup-recherche-le-perimetre-restant-a-definir

L'objectif est tout d'abord d'identifier les pratiques de développement dans la communauté Enseignement Supérieur et Recherche, au travers d'une enquête auprès de tous les membres de cette communauté amenés à développer du logiciel.

Cette enquête a été réalisée au printemps 2010 et a fait l'objet d'une très large diffusion, tant dans les réseaux métiers (Calcul, DevLog, ResInfo) que dans la communauté Plume et dans les structures de recherche (Instituts du CNRS, GDR …). Plus de 300 personnes ont répondu à cette enquête qui a été dépouillée en juillet 2010.

Elle permet d'avoir une idée des pratiques de développement actuelles dans les laboratoires de recherche, ainsi que des besoins exprimés par les personnes pratiquant cette activité.

Ce document propose une analyse synthétique des résultats de ce questionnaire. La première partie permet d'identifier les profils des répondants, tant en terme de tutelles, que de types d'activités et de pratiques de développement. La deuxième partie résume les outils actuellement utilisés dans le cadre du développement logiciel et la troisième partie permet d'identifier les besoins exprimés par les personnes ayant répondu à l'enquête. En conclusion, nous formulons quelques propositions.

Plan du document

1. Caractérisation des profils des répondants

2. Caractérisation des pratiques actuelles et outils utilisés

3. Caractérisation des besoins exprimés par rapport à une forge

4. Conclusions et propositions

Ce document a été rédigé par Véronique Baudin, Loic Gouarin et Violaine Louvet, après dépouillement de l'enquête, et complété par les remarques et corrections de Jean-Luc Archimbaud, Philippe Depouilly....

1. Caractérisation des profils des répondants

Le nombre de personnes ayant rempli le questionnaire est de 309. Dans ces réponses, on compte 204 questionnaires complets et 105 incomplets. Nous nous limiterons dans la suite de ce document à l'analyse des réponses complètes.

L'ensemble des tutelles du milieu de la recherche académique sont assez bien représentées. Nous comptons 86 personnes issues du CNRS et 38 personnes issues des Universités. Nous retrouvons également d'autres établissements publics. Si nous les donnons par ordre d'importance, nous avons l'INRA, l'INRIA, l'ENS, le CEA, l'INSA, …

Parmi ces personnes, 60% sont des ingénieurs et un peu plus de 28% sont des chercheurs et enseignants-chercheurs. Quelques doctorants ont répondu au questionnaire (7%). En revanche, très peu de techniciens y ont répondu (seulement 1,5%). L'activité de développement est, pour la plupart, permanente avec un peu plus de 64% des répondants, contre un peu plus de 31% pour lesquels cette activité est occasionnelle. Si nous regardons un peu plus finement comment se répartissent les fonctions de chacun dans ces deux formes d'activités de développement, nous constatons que la plupart des personnels disant développer de manière permanente sont des ingénieurs. Ces réponses semblent cohérentes avec les fonctions principales de ceux-ci. Concernant le développement occasionnel, les personnels sont partagés entre les ingénieurs et les chercheurs et enseignants-chercheurs. Les doctorants ont plus une activité de développement permanente avec 60% d'entre eux.

Les types de développement sont assez bien répartis et ne dépendent pas du type d'activité scientifique. Nous retrouvons dans les réponses les types suivants : développements web, création de logiciels de soutien, de bibliothèques, de codes de calcul et de composants logiciels. Si nous regardons les activités scientifiques des personnes réalisant des développements web, nous constatons qu'il n'y pas de liens forts avec leurs thématiques scientifiques. Nous pouvons donc en déduire que le développement web est annexe (création de sites web pour valoriser des projets). Nous constatons également que, les développeurs permanents développent des IHM pour leurs projets ce qui n'est pas encore le cas des développeurs occasionnels.

Ces développements font partie de projets internes ou externes à la structure et nous pouvons donc en déduire facilement qu'il n'y a pas en règle générale de développement à titre personnel. La majorité des codes développés sont publics ou destinés à le devenir. En règle générale, la diffusion se fait avec maintenance sauf pour les développeurs occasionnels qui peuvent diffuser sans maintenance. Le support semble être un point important pour les développeurs permanents. On peut également remarquer que les développements réalisés sont destinés soit à une diffusion ciblée, soit à une diffusion large.

Plus de 70% de ces développements se font en interaction avec des personnes extérieures, qui sont pour la plupart des ingénieurs et des chercheurs ou enseignants-chercheurs. Les disciplines de ces extérieurs sont essentiellement l'informatique, la physique, le calcul scientifique. La méthode de développement la plus utilisée est la méthode itérative (enrichissement du code par étapes successives : développement puis test par l'utilisateur final pour chaque étape). Nous retrouvons ensuite les méthodes agiles et l' "extreme programming".

2. Caractérisation des pratiques actuelles et outils utilisés

Dans cette enquête, nous avons interrogé les développeurs sur les différents outils qu'ils utilisent (gestion de version, forum, liste de diffusion, gestionnaire de tâches, ...). Les résultats obtenus nous permettent d'évaluer leur taux d'utilisation dans la communauté développeurs de l'enseignement supérieur et la recherche. Il est à noter que ces outils sont généralement présents dans une forge, outil offrant un ensemble d'outils permettant de développer dans des conditions optimales.

2.1 Outils de gestion de version

96,9% des développeurs permanents utilisent un système de gestion de version. Nous retrouvons le même pourcentage pour les développeurs occasionnels. Cet outil de développement est donc complètement entré dans les pratiques habituelles de tous les types de développeurs.

Nous pouvons distinguer 3 outils principalement utilisés : cvs (37,43% d'utilisation), Fiche Plume subversion (80% d'utilisation) et Fiche Plume git (21% d'utilisation). L'évolution naturelle correspond au degré de maturité de ces outils : abandon progressif de cvs, usage intensif de subversion et glissement vers des systèmes décentralisés comme git.

Il est important de noter que ces systèmes sont plutôt installés en local : 87% des développeurs pratiquant Git l'utilisent en local, 89,7% pour subversion et 73,9% pour cvs.

A noter enfin que 13% des répondants utilisent un autre logiciel de gestion de version. Les plus cités sont : mercurial (46%), bazaar (19%) et darcs (11%).

2.2 Outils de forum

Ces outils semblent très peu exploités dans le cadre des développements logiciels au niveau des laboratoires de recherche : seul 26% des répondants déclarent utiliser un système de ce type. Par ailleurs, dans ce cas, les outils cités correspondent essentiellement à des logiciels de forge.
L'emploi de forums est donc directement lié à l'usage d'une forge.

2.3 Outils de listes de diffusion

36% des répondants déclarent ne pas utiliser de listes de diffusion pour les utilisateurs et/ou les co-développeurs des codes. Ceux qui ont recours à ces outils le font majoritairement en local (62%).

2.4 Outils de suivi de tâches

63% des personnes n'utilisent aucun outil de suivi de tâches. Les autres pratiquent massivement Fiche Plume trac (à 64%). Nous pouvons noter une différence selon le degré d'activité de développement : 41,7% des développeurs permanents déclarent utiliser un système de suivi de tâches contre 27% pour les développeurs occasionnels.

2.5 Outils de génération de documentation

Les outils de génération de documentation sont globalement assez utilisés, par 71,2% des développeurs permanents et 63,5% des développeurs occasionnels.
Les systèmes les plus cités sont doxygen et javadoc.

2.6 Communication autour des projets

La communication et l'échange d'information autour des projets de développement logiciel passent majoritairement par la mise en place de site web dédié (64%) sans pour autant y associer des outils de calcul de statistiques d'utilisation et de téléchargements (seulement 22% des sites en sont équipés).

2.7 Autres outils

Les autres outils mentionnés dans la pratique du développement de logiciels sont en général des IDE comme Eclipse (souvent cité) et des outils de construction, d'optimisation et de tests (autoconf , valgrind , gcov...).

2.8 Utilisation de forges

D'une manière générale, les outils de forges sont peu utilisés : seul 32.6% des développeurs permanents et 31.7% des développeurs occasionnels ont recours à ces systèmes.

Les trois forges les plus citées par les personnes qui y ont recours sont :

Il faut noter également la multiplication de forges locales, dédiées à un établissement ou à un laboratoire.

Le choix d'un hébergement se fait principalement selon les critères suivants :

  • proximité contextuelle (lien avec la communauté, la structure d'appartenance) ou géographique
  • visibilité externe, diffusion large
  • facilité et simplicité d'utilisation, réactivité du support, flexibilité
  • pérennité

A noter que le temps de réponse du serveur hébergeant la forge est souvent vu comme un point à améliorer.

Pour résumer l'analyse des pratiques actuelles, on peut mettre l'accent sur les points suivants :

  • L'utilisation des systèmes de gestion de version est une pratique habituelle de tous les développeurs. Ces outils sont essentiellement installés de façon locale.
  • Les outils de génération de documentation sont assez massivement utilisés.
  • La pratique des autres outils comme les outils de gestion de tâches ou les outils de forums semble très liée à l'utilisation d'une forge.
  • La communication autour des projets de développement passe majoritairement à travers des sites web dédiés autonomes.
  • De manière générale, les forges sont peu utilisées, et il semble exister un nombre important de forges locales (niveau laboratoire, service ou établissement). Cette proximité contextuelle et/ou géographique est un point essentiel dans la motivation à héberger ses projets sur un site particulier. De même, les aspects visibilité externe, facilité et simplicité d'utilisation sont des critères décisifs du choix de l'hébergement.

3. Caractérisation des besoins exprimés par rapport à une forge

La dernière partie de l'enquête a concerné l'identification des besoins des utilisateurs en termes de forges. Ces besoins ont été listés par rapport à des besoins généraux ou globaux sur la forge, des besoins liés à chaque projet développé, aux services attendus de l'équipe administrant une forge. Nous avons proposé un ensemble de besoins et donné la possibilité aux personnes ayant répondu de compléter ces propositions. Pour chaque catégorie, nous donnerons les principaux besoins proposés par l'enquête ainsi que les besoins exprimés.

93,6% des personnes ayant répondu à cette enquête ont noté les besoins listés. Ce chiffre est à comparer aux 32% des développeurs utilisant déjà une forge. Les avis donnés ne sont donc pas dûs uniquement à des utilisateurs de ces outils, mais également à d'éventuels futurs utilisateurs de ceux-ci. Les résultats sont donnés en fonction des réponses des développeurs permanents (P) ou occasionnels (O).

3.1 Besoins globaux

Le classement par ordre de préférence donne les résultats suivants concernant les besoins globaux au niveau de la forge :

  • Recherche parmi les projets
  • Catégorisation des projets ; Bibliothèques de bouts de code (P et ordre inverse pour O)
  • Affichage, gestion de nouvelles (P) ; Recherche, invitation de développeurs (O)

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Affichage des projets par entité / laboratoire
  • Recherche de développeurs par champs ou domaine de compétences : langages / méthodes / domaine d'application …
  • Aide au choix de la licence et de la diffusion.

3.2 Besoins concernant les projets déposés

Le classement par ordre de préférence donne les résultats suivants concernant les besoins au niveau des projets déposés sur la forge :

  • Outils de gestion de versions, forum (P) ; Informations générales sur le projet (O)
  • Informations générales sur le projet (P) ; Système de suivi (O)
  • Système de suivi (P) ; Outils de gestion de versions, forum (O)
  • Listes de discussion , Site Web (P et ordre inverse pour O)
  • Wiki (P) ; FAQ (O)
  • FAQ (P) ; Nouvelles, annonces (O)
  • Gestion de tâches

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Citations des publications concernant le projet
  • Tests de non régression et intégration continue
  • Outils d'automatisation de création de paquetage
  • Hébergement des documents produits par doxygen, javadoc …
  • Vérificateur de liens
  • Accès à une ferme de compilation et de tests avec différentes architectures (tests de portabilité)
  • Analyse de code
  • Mots-clé, tags

3.3 Besoins concernant les services

Le classement par ordre de préférence donne les résultats suivants concernant les besoins au niveau des services disponibles sur la forge :

  • Sauvegardes
  • Assistance aux porteurs de projets
  • Ouverture aux projets publics et privés

Parmi les autres fonctionnalités données par les personnes ayant répondu à l'enquête, on peut extraire les points suivants :

  • Simplicité d'utilisation
  • Plateforme permettant de mutualiser tout type de travaux scientifiques : données expérimentales, modèles, outils de calcul, pilotage d'expérience à distance, publications …
  • Pour les projets SHS notamment, outils de publication/transformation de sources encodées en xml

4. Conclusions et propositions

L'enquête réalisée dans le cadre du projet « Forge ESR » de Plume a permis d'identifier les pratiques et besoins des membres de la communauté Enseignement Supérieur et Recherche dans le domaine de l'hébergement des développements logiciel des laboratoires.

La première partie de cette analyse montre que le profil des personnes ayant répondu à cette enquête reflète bien la diversité des cadres de travail, des activités et des types de développement du milieu de la recherche académique.

Les pratiques actuelles se résument essentiellement à une pratique intensive des outils de gestion de version, en particulier subversion, et à une utilisation courante d'outils de génération de documentation.
Cependant, il semble que l'usage d'autres types d'outils soit plus confidentiel.
Un aspect important est le fait que la plupart des outils pratiqués sont installés de façon locale à la structure d'appartenance du développeur.

Les forges existantes sont globalement peu utilisées, mais les besoins exprimés sont importants.

D'une façon globale :

  • les forges sont souvent vues comme des "usines à gaz" manquant de simplicité,
  • l'aspect visibilité est un point important de l'intérêt d'une forge,
  • la proximité géographique ou thématique est un critère essentiel dans le choix de l'outil d'hébergement.

Il semble donc nécessaire :

  • d'accompagner les développeurs vers l'utilisation des forges,
  • de respecter le critère de proximité pour les hébergements,
  • de s'assurer que les hébergements existants ou à venir proposent les outils répondant aux besoins exprimés dans cette enquête.

Dans ce but, nous suggérons un certain nombre de propositions afin d'améliorer l'environnement de travail des personnes qui développent des logiciels dans les laboratoires de recherche, d'augmenter la visibilité de ces développements et d'encourager les relations entre ces personnes.

Proposition 1

Réfléchir et développer un argumentaire fort pour promouvoir l'usage des outils collaboratifs comme les forges logicielles. Cette réflexion pourrait se réaliser dans le cadre d'un groupe de travail du réseau DevLog en lien avec le groupe Calcul et le projet Plume.

Proposition 2

Favoriser et encourager tout type de formation liée à l'usage des outils de développement collaboratifs et des forges en particulier. Ces formations ont vocation à être proposées dans le cadre des réseaux métiers, mais aussi par les services de formation permanente des établissements.

Proposition 3

Élaborer un scénario pour répondre aux besoins exprimés lors de l'enquête concernant la mise à disposition d'outils à vocation nationale.

Différents scénarios peuvent être proposés :

  1. Scénario 1 : Mise en œuvre d'une forge nationale pour la communauté « Enseignement Supérieur et Recherche »

    Les forges nationales existantes imposent des contraintes d'utilisation qui ne sont pas toujours compatibles avec les besoins des utilisateurs, notamment en terme d'hébergement de projets privés. Une des possibilités serait donc de proposer une forge nationale levant cette contrainte, et dont les outils constituants pourraient répondre aux besoins exprimés dans l'enquête.

    L'intérêt principal de ce scénario est de coller réellement aux besoins des développeurs.

    Cependant, il y a un certain nombre d'inconvénients :

    • ce scénario ne prend pas du tout en compte l'existant et notamment le grand nombre de petites forges de laboratoires ou de services qui ont déjà été déployées,
    • l'hébergement d'une telle forge suppose un consensus entre les différents établissements de recherche concernés (CNRS, Universités…), de même que la répartition entre ces entités des financements et la mise à disposition de ressources (moyens humains et matériels).
  2. Scénario 2 : Référencement et informations autour des forges existantes

    L'enquête a montré qu'il existait un nombre non négligeable de forges déjà installées dans certaines structures en plus des forges référencées dans la FAQ-Forge de PLUME

    Ce deuxième scénario consiste à recenser et référencer toutes les forges existantes afin que les développeurs soient informés des outils disponibles, de leurs potentialités et des contraintes d'utilisation associées.

    • L'avantage principal de cette solution est l'utilisation de l'existant et une mise en œuvre simplifiée, l'hébergement de ce référencement pouvant se faire sur un serveur comme Plume.
    • L'inconvénient est de ne pas proposer d'alternatives à l'existant, notamment pour les personnes n'appartenant pas aux structures proposant un hébergement ou ayant des contraintes de confidentialité pour leur projet.
  3. Scénario 3 : Création d'un portail de forges et accompagnement pour la mise en place d'outils d'établissement ou de service

    Ce dernier scénario consiste comme le précédent à recenser sur un même portail l'ensemble des forges des différentes structures existantes pour faciliter leur accès . Il va plus loin dans le sens où il serait proposé un accompagnement spécifique pour la mise en place de forges dans les entités intéressées, le partage d'expérience, la mise en commun d'informations…

    Les principaux avantages de ce scénario sont donc :

    • La prise en compte de l'existant tout en permettant une ouverture vers de nouveaux outils et services. La mutualisation des expériences et des informations faciliterait l'émergence de nouveaux hébergements.
    • Le fait de conserver l'existant permettrait aussi de préserver la visibilité, l'autonomie et l'indépendance des établissements et laboratoires en terme de développement logiciel.
    • Cette mutualisation faciliterait également l'organisation de formations.
    • Enfin, les moyens humains et financiers nécessaires seraient moindre par rapport au premier scénario.

Commentaires

Comment participer à la suite

Comment aider à avancer concrètement pour la suite ?

Par exemple, dans le projet COCLICO (voir fiche PLUME), nous travaillons sur des mécanismes de moissonage des informations des forges, qui pourraient permettre d'avancer vers des implémentations interopérables (standardisation) permettant de construire des portails pour les institutions.

Où peut-on participer à la suite ?

Commentez...

Développeurs, n'hésitez pas à ajouter des commentaires...