Cycle de vie des logiciels de recherche
Livrable 1 du sous-groupe 1 « On the Software Lifecycle » de la Task Force sur l’infrastructure pour des logiciels de recherche de qualité
Septembre 2023
>> Lien vers le document original
Approches en matière de développement de logiciels : produits, projets ou plateformes
Cycle de vie des logiciels de recherche
- Initialisation
- Planification
- Mise en œuvre
- Publication
- Déploiement et intégration de la plateforme
- Retour d’information par la communauté
Le cycle de vie des logiciels de recherche et l’infrastructure EOSC
Résumé
Les logiciels développés dans le cadre de la recherche font l’objet d’une attention accrue. Ceux-ci sont désormais de plus en plus souvent considérés comme de véritables produits de recherche, au même titre que les articles scientifiques et les publications de données de recherche. En vertu de scénarios utilisateurs représentatifs, nous avons identifié et caractérisé les différentes phases et étapes par lesquelles le processus de développement d’un logiciel de recherche peut passer, définissant ainsi le « cycle de vie d’un logiciel de recherche ». Diverses approches de développement de logiciels telles que l’orientation produit, projet ou plateforme sont également décrites. Nous concluons ce rapport avec les recommandations sur les composants d’infrastructure de l’EOSC nécessaires pour soutenir les processus et les plateformes identifiés.
Introduction
Ce document correspond au livrable 1 du sous-groupe 1 « On the Software Lifecycle » de la Task Force EOSC « Infrastructure for quality research software » [1]. Afin d’atteindre les objectifs de la Task Force, il est impératif de parvenir à une compréhension commune des processus actuels en matière d’ingénierie logicielle de recherche, en particulier du cycle de vie des logiciels de recherche. L’objectif du présent document est d’illustrer ce cycle de vie et la manière dont ses instanciations pour des projets logiciels particuliers sont influencées par les différents groupes de développeurs et leurs intentions. Nous nous concentrons ici sur les logiciels développés et maintenus dans le cadre de la recherche qui peuvent être intégrés dans des infrastructures de recherche ouvertes telles que l’EOSC. Nous mentionnons les connexions possibles avec l’infrastructure actuelle et future de l’EOSC pour soutenir le cycle de vie des logiciels de recherche. De manière générale, les logiciels de recherche doivent être aussi ouverts que possible et refléter les principes FAIR dans leur conception, en particulier l’interopérabilité et la réutilisation[2].
Bien qu’il existe différents modèles de cycle de développement de logiciels[3], les spécificités des logiciels de recherche[4] doivent être examinées. Plusieurs considérations liées aux processus d’ingénierie logicielle dans les logiciels de recherche ont été avancées. Le présent document s’inspire de ces sources. Par exemple, les lignes directrices du Centre allemand pour l’aéronautique et l’astronautique (DLR) en matière d’ingénierie logicielle[5] fournissent une définition utile des « classes d’application », allant de la classe 0 (usage personnel, portée limitée) à la classe 4 (usage critique). En fonction de la classe, des directives plus strictes s’appliquent en ce qui concerne l’ingénierie logicielle, la documentation, les tests, la gestion du changement, etc. The Turing Way et CODE REFINERY[6] contiennent de nombreuses informations sur les meilleures pratiques en matière de développement de logiciels de recherche et de recherche reproductible. Une caractérisation des projets de logiciels de recherche et leurs transitions entre différentes classes d’application ont été analysées pour les logiciels financés par la NSF[7]. Quatre configurations d’organisation différentes ont été identifiées : groupe d’auteurs, laboratoire, groupe d’outils et production par les pairs.
Le reste de ce document est organisé comme suit. Nous décrivons d’abord différents scénarios utilisateurs rencontrés dans le développement de logiciels de recherche, allant d’un chercheur individuel créant un logiciel pour un usage personnel à une communauté scientifique potentiellement vaste développant un service bien établi. Nous étudions ensuite différentes approches dans le développement de logiciels en fonction des différentes lignes de conduite des développeurs ou responsables de la maintenance. Cette analyse est suivie d’une présentation du cycle de vie des logiciels de recherche, où nous formulons des recommandations pour faciliter et mettre en œuvre les différentes étapes. Nous concluons en créant des liens explicites entre le cycle de vie des logiciels de recherche et l’EOSC.
Scénarios utilisateurs
Dans ce chapitre, des scénarios utilisateurs sont présentés pour ouvrir la voie à la discussion ultérieure sur le cycle de vie des logiciels et de la recherche.
- Une personne crée un logiciel de recherche pour son propre usage (par exemple, un doctorant).
Sur la base d’une question de recherche, un logiciel est créé par une seule personne dans le but spécifique de répondre à cette question et de produire un résultat de recherche (article, jeu de données, etc.). Le processus de planification et de développement reste simple. Les pratiques de base en matière d’ingénierie logicielle (contrôle des versions, documentation et tests de base) doivent être appliquées. Des pratiques d’ingénierie logicielle plus avancées telles que le suivi des problèmes, le style de code, la couverture des tests, l’intégration et la livraison continues (CI/CD), les révisions du code, les outils de contrôle de la qualité du code, etc. ne sont souvent pas utilisées. Une fois le résultat souhaité obtenu, tous les résultats de la recherche doivent être publiés (article, jeu de données, flux de travail, logiciel, etc.) afin de garantir la reproductibilité des résultats. Après publication, le composant logiciel n’est souvent pas maintenu de manière active, bien qu’il puisse servir dans certains cas de base pour le prochain cycle (c’est-à-dire sur la base d’un retour d’information qui engendre d’autres questions de recherche). Ce type de logiciel peut être repris par d’autres personnes ou équipes, situation où un transfert de propriété intellectuelle et de droits d’accès doit être assuré. Une condition préalable à un tel transfert est de rattacher à l’outil logiciel une licence, de préférence une licence ouverte[8].
- Une équipe de recherche crée une application ou un flux de travail destiné à être utilisé au sein de l’équipe.
Les logiciels de recherche sont produits par une équipe pour répondre à une série de questions de recherche (souvent dans le cadre d’un projet de recherche plus large). Afin de permettre le développement de plusieurs membres de l’équipe et d’assurer une maintenance à plus long terme, il convient d’employer à la fois les pratiques d’ingénierie logicielle de base (contrôle des versions, documentation et tests de base) et une sélection de pratiques d’ingénierie logicielle plus avancées (suivi des problèmes, versions sémantiques, style de code, couverture des tests, CI/CD, révisions de code, contrôles de la qualité des codes, etc.). Une planification adéquate du développement est nécessaire pour promettre des versions régulières du logiciel. Ces versions sont utilisées pour répondre à des questions de recherche et produire des résultats de recherche (articles, jeux de données, etc.). Pour garantir la reproductibilité des résultats, les versions doivent être archivées et correctement citées dans les articles, les jeux de données, etc. Après publication, le cycle de développement continue de répondre à d’autres questions de recherche et de fournir des améliorations ou corrections au code existant.
Cette catégorie comprend par exemple des solutions logicielles permettant de simuler, d’exploiter et d’analyser les résultats de grandes expériences scientifiques ou, plus généralement, des appareils de mesure et leurs résultats.
- Une équipe ou communauté développe des logiciels de recherche en accès ouvert (éventuellement applicables à grande échelle).
Un logiciel est créé par une équipe (éventuellement répartie dans plusieurs organisations) pour répondre à un large éventail de questions de recherche. Les membres de l’équipe peuvent avoir des objectifs différents ou peuvent représenter une communauté d’utilisateurs. Les utilisateurs externes peuvent dépendre de ce logiciel, qu’ils contribuent ou non directement à son développement. Des techniques d’ingénierie logicielle de base et avancées doivent être exploitées pour garantir un processus de développement fluide, une qualité et une maintenabilité à long terme. Une bonne planification du développement devrait être mise en place pour coordonner les membres de l’équipe et fournir des versions régulièrement. Ce cycle de développement n’est souvent pas directement guidé par un (seul) cycle de recherche.
Au contraire, le retour d’information de la communauté (par exemple, le suivi des problèmes) est employé pour orienter les décisions en matière de maintenance et de développement.
La liste d’exemples dans différentes communautés, de loin non-exhaustive, comprend : Astropy (astronomie) ; ESMValTool (sciences de la Terre) ; VASP [9], FHI-aims (recherche sur les matériaux) ; Gromacs (dynamique moléculaire) ; Neuron, Nest, Genesis (neuroinformatique) ; root (physique des particules) ; Scikit-Learn (apprentissage automatique) ; Sat4J (optimisation et satisfaction booléenne). D’autres exemples peuvent être trouvés, par exemple, dans le Research Software Directory.
- Une équipe ou une communauté crée un service de recherche.
Une plateforme de services est un ensemble de composants logiciels qui est utilisé pour fournir des services à un grand nombre d’utilisateurs, dont la plupart profite de ces offres par le biais d’Internet (par exemple, les services en nuage). Ces composants logiciels peuvent être exécutés à un seul endroit ou être distribués sur du matériel virtualisé. Ils sont pour la majorité en accès ouvert, mais les services proposés ne sont pas nécessairement gratuits. Il n’est pas rare non plus que des services à source fermée permettent d’accéder à des données ouvertes.
L’objectif du développement et de l’exploitation d’une telle plateforme est de créer un ensemble de services durables et évolutifs pour un groupe cible défini. La valeur ajoutée par rapport aux solutions logicielles locales résulte notamment du fait que le stockage des données, les capacités de calcul et les options de communication sont proposés en plus des fonctions de base telles que la modélisation, l’analyse des données, la gestion de projet ou le développement de logiciels. Le besoin d’un développement, d’un déploiement et d’un fonctionnement continu (24h/24, 7j/7) ainsi que d’une évolutivité flexible requiert des méthodes de développement de logiciels spécifiques telles que le devops et le CI/CD. L’approche durable exige également des lignes directrices strictes en matière de développement et de qualité, des licences claires, un environnement de développement ouvert, une reconnaissance visible des contributeurs ainsi qu’un financement pérenne ou un modèle d’entreprise viable.
Ce type de plateformes dans la recherche compte, par exemple, D4Science (une solution soutenant le développement d’environnements de recherche virtuels), HIFIS (Helmholtz Federated IT Services) (plateforme de services numériques génériques), VIP (Virtual Imaging Platform) (plateforme d’imagerie médicale), VISA (Virtual Infrastructure for Scientific Analysis) (infrastructure d’analyse) ou VISPA (Visual Physics Analysis) (plateforme d’analyse des données de physique). Ces services ou plateformes sont de plus en plus souvent rassemblés sur le portail de l’EOSC.
Alors que les scénarios utilisateurs 1 et 2 sont généralement gérés par des personnes ou des groupes de personnes ayant un intérêt et un but communs en matière de recherche, le 3 et le 4 nécessitent une forme organisationnelle plus stricte, par exemple en créant une équipe d’encadrement ou en faisant intervenir efficacement une fonction de directeur technique, engagé ou endossé par l’auteur ou le chercheur principal initial. Les personnes et les groupes sont soutenus dans leurs objectifs de développement et de maintenance par différentes fondations ou organisations telles que la Fondation Apache Software, le Centre e-Science des Pays-Bas, la HEP Software Foundation ou Software Heritage. Si un projet de développement de logiciels sort du domaine de recherche, par exemple par sa complexité, son implication dans l’industrie ou un déploiement géographique mondial, il n’est pas couvert par les cas d’utilisation traités ici.
Il faut remarquer que les projets de logiciels peuvent évoluer de manière significative au fil du temps et peuvent donc passer d’une catégorie à l’autre. Il arrive souvent qu’un logiciel de recherche aujourd’hui largement employé, maintenu soit par une grande communauté, soit par un petit nombre de développeurs principaux, ait en fait commencé à l’échelle d’une initiative individuelle en réponse à une question de recherche dans une petite équipe ou communauté (voir par exemple l’évolution de Sat4J).
Les recommandations ou les exigences relatives aux logiciels de recherche doivent tenir compte de cette nature évolutive des logiciels de recherche.
Approches en matière de développement de logiciels : produits, projets ou plateformes
Diverses approches de développement de logiciels pour les produits, les projets et les plateformes sont adoptées dans les secteurs de la science et de l’industrie. Nous décrivons ci-après les principaux aspects de ces trois approches, principalement appliquées par le groupe de développeurs ou de responsables de la maintenance, qui doivent être pris en compte pour l’ensemble du cycle de vie du logiciel tel que décrit dans la prochaine section.
>> Orientation produit (cas typique dans le domaine de l’industrie)
- Rôles et responsabilités davantage dissociés entre les différents départements et les personnes, par exemple : le marketing, l’ingénierie des exigences, la gestion de produits, la gestion de projets, le développement, l’assurance qualité, notamment l’ingénierie logicielle professionnelle, les ventes, le service après-vente, le service et la formation.
- Planification et contrôle des projets (mise en œuvre, jalons, modèles de développement, objectifs en termes de temps, d’efforts et de coûts) généralement optimaux, feuille de route et lancements de nouveaux produits et de nouvelles versions prévus longtemps à l’avance.
- Orientation et calcul coûts/bénéfices tout au long du cycle de développement.
- Assurance qualité dans les différentes phases (développement, documentation du produit, essai sur le terrain, projets pilotes, publication).
- Visibilité et reconnaissance élevées, mais forte pression en ce qui concerne les délais, le budget et la réussite.
- Communauté souvent fermée et source généralement fermée, à l’exception notable de Kubernetes, Docker et TensorFlow, entre autres.
>> Orientation projet (cas typique dans le domaine de la science)
- Commence généralement par une idée visant à résoudre un problème (dans la plupart des cas, un défi pour l’équipe ou l’entreprise), parfois sur la base d’une vision, les exigences évoluant au fil du temps.
- Objectifs moins clairs en termes de temps, d’efforts et de coûts.
- Évolution de l’équipe et du budget au fil du temps.
- Visibilité et reconnaissance limitées, mais parfois peu de pression en ce qui concerne les jalons, le budget et le succès.
- Dans la recherche, souvent intégrée dans une communauté ouverte (forte coopération), principalement en accès ouvert.
Les quatre scénarios utilisateurs mentionnés ci-dessus montrent des exemples dans le domaine de la recherche de développement de logiciels basés sur des projets qui, dans de nombreux cas, ne sont pas encore mis en œuvre de manière durable. Le développement de « logiciels internes » orienté vers le projet se produit également dans le domaine de l’industrie. Il n’est pas tellement axé sur le marketing et les ventes, mais reste orienté sur les coûts et les jalons.
>> Orientation plateforme (cas typique dans les domaines de la science et de l’industrie)
- Orientation coûts/bénéfices : calculés tout au long du cycle, avec pour objectif global d’augmenter le nombre d’utilisateurs et de développeurs (plutôt que de maximiser directement la monétisation).
- Planification et contrôle des projets : généralement optimaux, avec une feuille de route claire pour les versions (pour assurer la coordination avec les développeurs qui créent des produits basés sur la plateforme).
- Communauté ouverte et souvent en open source.
- Techniques de développement agiles généralement employées.
- Processus de test et de déploiement hautement automatisé.
- Prise en charge des données et des différents services autour du logiciel de base.
- Apport d’un certain niveau de durabilité pour les utilisateurs de la plateforme, mais la confidentialité des données constitue aussi un problème.
- Développement de structures de soutien et de leurs ressources (par exemple, système de tickets, service d’assistance, documentation/wiki).
Par l’introduction de « classes d’application » (voir l’introduction), les exigences de ces approches peuvent être prises en compte dans les premières phases du cycle de vie du logiciel afin de parvenir à un développement logiciel plus professionnel dans le domaine de la recherche. Ce constat est corroboré par la définition de standards et de mesures minimales concrètes pour les classes d’application dans les lignes directrices et les politiques de développement de logiciels pour un nombre croissant d’instituts de recherche.
Cycle de vie des logiciels de recherche
La figure 1 comporte une représentation graphique du cycle de vie d’un logiciel de recherche. Elle représente une boucle qui se répète généralement tout au long de la durée d’un projet de logiciel de recherche. Au cours d’une instanciation spécifique d’un cycle, les six étapes décrites ne sont pas forcément toutes incluses. Nous notons que cette représentation n’est pas nécessairement exhaustive en raison de la complexité et de l’individualité des diverses approches adoptées par différentes personnes, groupes et communautés. Les différentes étapes et relations du graphique sont décrites ci-dessous.
Plus récemment, des plans de gestion des logiciels (PGL ou SMP) ont été proposés pour gérer les cycles de vie des logiciels. Comme les plans de gestion de données (PGD ou DMP), les PGL sont des documents qui décrivent l’objectif du logiciel et la manière dont le logiciel de recherche sera géré, à la fois pendant la durée de vie du projet et après sa clôture. En rendant ces informations explicites, les PGL aident à mettre en place un cycle de développement approprié pour les logiciels de recherche, donnent un aperçu des ressources nécessaires pendant le développement et garantissent que l’accessibilité à long terme du logiciel est correctement prise en compte.
Comme il n’existe actuellement aucun modèle de PGL accepté de manière universelle, plusieurs organisations ont créé leur propre modèle, ainsi qu’une liste de vérification et des recommandations et guide sur la création d’un PGL. Les aspects importants à prendre en considération lors de la mise en place d’un PGL sont la classification des logiciels, la sélection des étapes nécessaires à partir de la figure 1, ainsi que la licence appropriée, l’organisation de la gestion de la propriété intellectuelle et la transition entre différentes classes de logiciels. Puisque ces étapes ne sont généralement pas planifiables a priori, un PGL évolue souvent au cours d’un projet.
Figure 1 : Représentation graphique du cycle de vie d’un logiciel de recherche
1. Initialisation
Une question de recherche, une nouvelle demande de service ou de fonctionnalité (par exemple, service de données, automatisation des flux de travaux) ou des appels d’offres de bailleurs de fonds (par exemple, de l’UE) lancent la phase de planification.
2. Planification
La planification du développement d’un logiciel de recherche se fait généralement dans le cadre d’un mémoire d’étudiant (licence, master, doctorat) ou pour un projet de recherche plus large comprenant la préparation d’articles scientifiques concrets. De plus, les nouvelles versions des projets de logiciels de recherche en cours depuis plus longtemps déclenchent souvent le début d’un nouveau cycle.
La phase de planification peut tirer parti ou se composer d’une analyse des besoins (pour tous les niveaux), d’une proposition de valeur (pour les produits logiciels) ou d’une étude de marché ou de communauté afin de comprendre le public (pour les produits logiciels ou les plateformes). Une feuille de route pour le développement initial et les étapes ultérieures peut également s’avérer utile.
3. Mise en œuvre
Selon le contexte, chaque cycle illustre le flux de travail typique pour la mise en œuvre, par exemple, d’une nouvelle fonctionnalité dans le cadre du développement d’un logiciel ou d’une correction de bogue dans le cadre de sa maintenance[10].
Dans les grands projets en particulier, toutes les étapes d’un même cycle peuvent être très élaborées, et, simultanément, plusieurs cycles coexistent dans le même temps, ce qui correspond à la mise en œuvre en parallèle de nouvelles fonctionnalités, ou à la correction de bogues. Dans les projets réalisés par une seule personne, comme dans le cas de travaux d’étudiants, la mise en œuvre est naturellement effectuée de manière plus séquentielle. Les contrôles de progression par des tiers peuvent manquer et, généralement, aucun service ou cadre de CI/CD n’est utilisé.
La phase de mise en œuvre peut être facilitée, entre autres, par un contrôle des versions et des systèmes de gestion des versions (y compris la gestion de la publication), des services de suivi des problèmes et de révision de code, des tests ainsi que des services et une infrastructure de CI/CD.
Les pratiques et les outils de facilitation peuvent varier selon les étapes du logiciel, voir, par exemple, les classes d’application dans les lignes directrices du DLR en matière d’ingénierie logicielle.
4. Publication
Si les logiciels méritent d’être publiés en tant que tels, actuellement, dans le domaine de la recherche, la publication de logiciels de recherche accompagne en général l’élaboration et la publication d’un document tel qu’un mémoire d’étudiant, un article scientifique ou un rapport de projet. D’autres éléments comme les données d’entrée et de résultat, les conteneurs, les carnets de laboratoire ou les descriptions de flux de travaux devraient idéalement permettre d’obtenir un condensé ou objet de recherche intégré. Les logiciels de recherche doivent en eux-mêmes être cités et faire l’objet d’une référence dans le document. Les ingénieurs en logiciel de recherche jouent souvent un rôle majeur dans le développement du logiciel, sans nécessairement devenir co-auteurs des articles ou des jeux de données qui en découlent. Il est donc important de reconnaître leurs contributions par le biais de citations de logiciels. Outre la publication du logiciel lui-même, il existe plusieurs revues spécialisées qui offrent le service de publication d’articles sur les logiciels de recherche.
L’étape de publication/déploiement des logiciels de recherche peut être facilitée, par exemple, par (i) des cadres de livraison continue[DM1] , (ii) des services de publication, (iii) des services d’archivage ou (iv) des services de formation et d’assistance, (v) des répertoires de logiciels de recherche.
Un lien entre les logiciels et d’autres objets de recherche peut être établi dans des répertoires de logiciels de recherche, ce qui nécessite des identifiants appropriés, par exemple en créant des DOI sur Zenodo ou des identifiants Software Heritage.
Pendant la préparation de la publication au plus tard (mais de préférence à un stade aussi précoce que possible), des métadonnées doivent être associées au logiciel. Plusieurs standards sont utilisés et en cours d’harmonisation par l’intermédiaire de plusieurs groupes liés à l’EOSC. Les standards actuellement utilisés sont le Citation File Format et CodeMeta.
La trouvabilité peut être optimisée par l’ajout d’une citation en direction du logiciel et de références dans les articles qui l’accompagnent.
5. Déploiement et intégration de la plateforme
Les logiciels ne sont pas seulement fournis sous forme de codes sources et d’exécutables, ils le sont aussi par le biais d’une utilisation directe au sein des plateformes (voir le scénario utilisateur 4). Il s’agit d’un logiciel en tant que service qui comporte certains problèmes spécifiques supplémentaires comparativement à un éditeur de logiciels sur site, tels que les interfaces d’authentification et d’autorisation, les données, le suivi, l’extensibilité, la comptabilité et la maintenance en continu.
Cette intégration peut être lancée par le développeur de logiciels en fournissant des logiciels et des données dans des carnets Jupyter, des conteneurs ou des machines virtuelles comme première étape ou étape intermédiaire vers un logiciel en tant que service.
Il s’agit ici du processus de déploiement et d’intégration du logiciel spécifique, la plateforme elle-même étant un ingrédient nécessaire, mais qui n’est souvent pas au centre du cycle de développement du logiciel. L’intégration et les plateformes sont deux éléments nécessaires à l’intégration de l’EOSC.
La publication en libre accès devrait être privilégiée avant l’intégration à une plateforme, mais d’autres options sont également possibles, en gardant à l’esprit que pour les logiciels en tant que service, un modèle commercial valide peut être nécessaire (il existe par exemple des modèles pour obtenir une édition communautaire gratuitement et une édition professionnelle n retour d’une adhésion financière).
6. Retour d’information par la communauté
La forme, la quantité et la rapidité des commentaires de la communauté sur les logiciels de recherche peuvent varier considérablement en fonction de la taille, de la maturité, de la gamme d’applications et du public ciblés. En plus de la diffusion des articles scientifiques décrivant le logiciel (et en faisant la publicité), des présentations lors de conférences et d’autres réunions peuvent contribuer à créer et à développer une communauté d’utilisateurs.
L’étape du retour d’information de la communauté peut être facilitée par des canaux de communication appropriés (centre d’assistance, système de suivi des problèmes, listes de diffusion électronique, applications de chat…) ou même par un canal mis en place pour permettre à la communauté de contribuer à la qualité du logiciel en général ou de l’évaluer.
Continuité ou fin du cycle
Le retour d’information et la réutilisation peuvent soit engendrer de nouvelles questions de recherche qui déclenchent un autre cycle complet (de 1 à 6 ci-dessus), soit déclencher des cycles de mise en œuvre plus modestes au titre de la maintenance du logiciel, ou provoquer l’arrêt du développement ou service. C’est surtout à ce stade que les scénarios utilisateurs peuvent être modifiés et que les classes d’application peuvent être redéfinies.
Le cycle de vie des logiciels de recherche et l’infrastructure EOSC
Une infrastructure pour les logiciels de recherche dans l’EOSC devrait prendre en charge tous les scénarios utilisateurs et le cycle de vie des logiciels de recherche tel que décrit ci-dessus, en conformité avec les règles de participation de l’EOSC. Afin de permettre un large soutien aux logiciels et services, des composants d’infrastructure pour l’agrégation, la communication, le développement et l’archivage sont essentiels.
Il existe deux catégories d’actions résultant des besoins du cycle de vie des logiciels.
L’une d’elles concerne la gouvernance, la sensibilisation et le soutien :
- communiquer la valeur ajoutée de l’utilisation et de l’intégration des logiciels de recherche et des services liés aux logiciels dans l’EOSC ;
- apporter un soutien à la transition des projets et services logiciels vers l’écosystème de l’EOSC ;
- soutenir les communautés scientifiques dans la transition entre les différents niveaux de classes de logiciels et leur pérennité, en particulier dans le respect de programmes mécanismes de financement limités dans le temps ;
- soutenir les activités d’enseignement et de formation[11] sur le développement et l’ingénierie logicielle, notamment en coordonnant les efforts dans toute l’Europe ; non seulement pour les professionnels, mais aussi en suivant l’approche de la « formation du formateur » afin d’élargir le champ d’action.
L’autre concerne la mise en œuvre technique :
- fournir et soutenir des plateformes de développement de logiciels ouvertes et durables ainsi que la fédération de plateformes établies pour favoriser une large collaboration et une fertilisation croisée ;
- apporter une infrastructure de soutien pour assurer et améliorer la qualité des logiciels de recherche, y compris l’application de métadonnées, de licences et d’indicateurs de qualité appropriés ;
- fournir des répertoires, des entrepôts, des registres et des archives de logiciels, au sens d’archives, d’éditeurs et d’agrégateurs selon le rapport SIRS sur les infrastructures logicielles de recherche[12] ;
- intégrer ou relier les infrastructures communautaires, nationales et mondiales (par exemple GitHub, OpenAire, Software Heritage, Zenodo) dans l’écosystème de l’EOSC en garantissant la validité de l’identification et du contrôle d’accès employé ;
- proposer des outils d’aide à la collaboration pour les interactions entre les développeurs et les communautés d’utilisateurs, de préférence bien intégrés dans le service logiciel et la plateforme de développement.
Les logiciels de recherche doivent être considérés comme des composants de rang privilégié de la science ouverte, et les exigences qui en découlent doivent être intégrées dans la mise en œuvre d’une infrastructure EOSC pour les logiciels de recherche.
[1] Charte de la Task Force de l’EOSC sur les infrastructures pour des logiciels de recherche de qualité.
[2] Barker, M., Chue Hong, N.P., Katz, D.S. et al., Introducing the FAIR Principles for research software, Sci Data 9, 622, 2022, https://doi.org/10.1038/s41597-022-01710-x.
[3] Khan, N.A. (2021). Research on Various Software Development Lifecycle Models, In : Arai, K., Kapoor, S., Bhatia, R. (éds), Proceedings of the Future Technologies Conference (FTC) 2020, Volume 3, FTC 2020, Advances in Intelligent Systems and Computing, vol 1290, Springer, Cham, https://doi.org/10.1007/978-3-030-63092-8_24.
[4] Gruenpeter, M., Katz, D.S., Lamprecht, A. et al., Defining Research Software: a controversial discussion (Version 1), Zenodo, https://doi.org/10.5281/zenodo.5504016.
[5] Lignes directrices du DLR en matière d’ingénierie logicielle, https://doi.org/10.5281/zenodo.1344612.
[6] Training and e-Infrastructure for Research Software Development, https://coderefinery.org.
[7] The Transition Project, https://hannahcohoon.com/transition.
[8] Cf. § 47 du rapport de décharge 2018 du Parlement européen https://www.europarl.europa.eu/doceo/document/TA-9-2020-0088_FR.pdf.
[9] The Vienna Ab initio Simulation Package (VASP), https://www.vasp.at/.
[10] Les sujets liés à la qualité des logiciels de recherche, tels que les styles de code, les programmes de test et les contrôles de vulnérabilité, sont traités en détail par cette Task Force, dans le livrable « Ensure Software Quality ».
[11] Voir également la charte de la Task Force de l’EOSC sur les programmes de formations et carrières en administration des données.
[12] Commission européenne, Direction générale de la recherche et de l’innovation, Scholarly infrastructures for research software: report from the EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS, Office des publications, 2020, https://data.europa.eu/doi/10.2777/28598.
Contributeurs
- Guy Courbebaisse, CGE et INSA Lyon – CREATIS Lab, France, https://orcid.org/0000-0001-6181-2000
- Bernd Flemisch, Université de Stuttgart, Institut de modélisation des systèmes hydrauliques et environnementaux, Pfaffenwaldring 61, 70569 Stuttgart, Allemagne, https://orcid.org/0000-0001-8188-620X
- Kay Graf, Université Friedrich-Alexander d’Erlangen-Nuremberg, Centre de physique des astroparticules d’Erlangen, Nikolaus-Fiebiger-Str. 2, 91058 Erlangen, Allemagne, https://orcid.org/0000-0002-1921-5568
- Uwe Konrad, Helmholtz-Zentrum Dresden-Rossendorf, Allemagne, https://orcid.org/0000-0001-8167-9411
- Jason Maassen, Netherlands eScience Center, Université libre d’Amsterdam, Pays-Bas https://orcid.org/0000-0002-8172-4865
- Raphael Ritz, Max Planck Computing and Data Facility, Giessenbachstr. 2, D-85748 Garching, Allemagne, https://orcid.org/0000-0003-4615-6804
OpenEdition vous propose de citer ce billet de la manière suivante :
isabelled (29 mars 2024). Cycle de vie des logiciels de recherche. EOSC dans le texte. Consulté le 30 avril 2025 à l’adresse https://doi.org/10.58079/w4s0