Maintenance logicielle dans la recherche
Édition Python Édition JVM Blog … bibliothèque —> La maintenance logicielle dans la recherche par Konrad Hinsen, publié le 26 févr. 2014 La maintenance logicielle est l’une des difficultés auxquelles les développeurs de logiciels scientifiques sont régulièrement confrontés.
C’est une activité importante, mais elle peut prendre beaucoup de temps et est rarement récompensée par les procédures d’évaluation actuelles. De plus, si vous gérez un grand projet logiciel, il est généralement difficile d’obtenir des financements pour sa maintenance. Étant donné que la maintenance logicielle est complexe et ne présente pas d’intérêt scientifique intrinsèque, nous devrions nous demander pourquoi elle est nécessaire et s’il est possible de réduire ce besoin. Tout d’abord, qu’est-ce que la maintenance logicielle ?
Merriam-Webster définit le verbe « maintenir » (maintain) comme le fait de garder (quelque chose) en bon état en effectuant des réparations, en corrigeant des problèmes, etc. Cela a du sens pour les équipements techniques qui se détériorent avec le temps en raison de l’usure mécanique, etc. Les logiciels ne se détériorent pas ; la maintenance doit donc avoir une signification différente lorsqu’elle s’applique au logiciel.
Je n’ai connaissance d’aucune définition consensuelle, voici donc la mienne : La maintenance logicielle consiste à modifier un logiciel pour l’une des deux raisons suivantes : Corriger des bogues. Maintenir le logiciel utilisable dans des environnements informatiques en évolution. Certains ajouteraient à cette liste les améliorations fonctionnelles, mais il ne s’agit pas vraiment de maintenance au sens propre, plutôt d’améliorations.
Cela est particulièrement vrai dans le cas des logiciels scientifiques, où une nouvelle fonctionnalité signifie souvent une nouvelle découverte scientifique. Premièrement, les bogues.
Comme pour tout logiciel, nous souhaitons que les bogues des logiciels scientifiques soient corrigés afin d’obtenir de meilleurs résultats à l’avenir. Cependant, nous devons également conserver la version boguée si une étude scientifique publiée l’a utilisée. C’est simplement une question d’honnêteté et de préservation du dossier scientifique : s’il existe une chance que le résultat d’une étude ait été influencé par un bogue dans le logiciel, les personnes examinant l’étude devraient pouvoir le découvrir.
Connexes : — Cours interactifs Python et science des données que vous codez directement dans le navigateur.
Elles doivent avoir accès exactement au même logiciel que celui utilisé à l’origine, et non pas seulement à son successeur amélioré d’aujourd’hui. Pour cette raison, il est en fait plus important de préserver le code utilisé dans une étude que de corriger les bogues.
ActivePapers a été conçu dans cet optique : chaque élément de données calculé dans un ActivePaper est lié au logiciel qui l’a produit. De plus, ce lien est strictement immuable après publication, car les ActivePapers sont publiés tout comme des copies électroniques d’articles et référencés via des DOI. On peut tricher avant la publication en modifiant un ActivePaper dans l’intention spécifique de commettre une fraude. ActivePapers ne prend pas en charge de telles actions, mais ne fait aucun effort pour prévenir la fraude non plus.
De telles fonctionnalités pourraient être ajoutées en protégeant les informations de provenance par des hachages, mais j’espère que cela ne sera pas nécessaire. Le deuxième problème, celui des environnements informatiques en évolution, est plus subtil. C’est un fait établi que tout dans le monde informatique (ordinateurs, systèmes d’exploitation, compilateurs, définitions de langages, bibliothèques, …) change rapidement, ce qui fait qu’un morceau de code source donné a peu de chances de fonctionner tel quel quelques années plus tard.
Coup de cœur des lecteurs : — Parcours de science des données basés sur des projets avec un terminal guidé et des ensembles de données réels.
Cela se produit pour deux raisons : (1) le progrès technique permet des ordinateurs et des logiciels toujours meilleurs, ce que les gens souhaitent, et (2) personne n’a d’intérêt vested dans la stabilité des plateformes informatiques ni le pouvoir de la garantir. Pour les fabricants de matériel et les fournisseurs de logiciels commerciaux, le changement rapide est le meilleur moyen de s’assurer que les clients achètent de nouvelles machines et mettent régulièrement à jour leurs licences. Il existe bien sûr au moins une communauté ayant un intérêt vested dans la stabilité des plateformes informatiques : la communauté de la science computationnelle.
Si nous pouvions exécuter notre logiciel 20 ans plus tard, sans modification, et obtenir les mêmes résultats, nous serions ravis. Nous ne voulons pas faire de maintenance logicielle, et la plupart d’entre nous ne peuvent raisonnablement pas maintenir les logiciels qu’ils développent pour leurs propres recherches au-delà de leurs besoins personnels immédiats.
Il est encore moins raisonnable de s’attendre à ce que quelqu’un maintienne le logiciel d’un autre, par exemple le logiciel laissé par un étudiant diplômé qui travaille désormais dans l’industrie. En pratique, seuls les logiciels communautaires largement utilisés sont maintenus sur des périodes suffisamment longues. Mais même les projets de recherche utilisant des packages largement utilisés et maintenus nécessitent généralement aussi un logiciel spécifique au projet, ne serait-ce que quelques scripts shell.
Et c’est l’une des raisons pour lesquelles la reproductibilité des études computationnelles est si mauvaise. La communauté scientifique pourrait-elle faire quelque chose à ce sujet ?
Je le crois, mais je ne suis pas optimiste quant à une action dans un avenir proche. Il est probable que les scientifiques continuent d’utiliser du matériel grand public pour le calcul scientifique, ce qui signifie qu’ils devront accepter l’évolution du matériel et des logiciels système associés, qui échappent à leur contrôle. Cependant, ils peuvent construire une plateforme stable au-dessus de ces environnements en constante évolution, du moins pour la partie purement computationnelle de leur travail. À un niveau fondamental, toutes les notations logicielles Turing-complètes sont équivalentes et peuvent être converties les unes dans les autres.
En pratique, des considérations de performance imposent une limite à la conversion de code, mais il reste possible de définir des représentations de code qui peuvent être traduites efficacement vers tous les types de matériel et de logiciels système sous-jacents, restant ainsi stables. Deux exemples concrets sont le bytecode JVM et la forme intermédiaire de LLVM . Le bytecode JVM existe depuis 20 ans et s’est avéré extrêmement stable.
La forme intermédiaire de LLVM n’est pas destinée à être stable, mais c’est parce que les développeurs de LLVM ne veulent pas limiter leurs options futures en s’engageant sur une représentation stable. Le projet PNaCl de Google tente d’ignorer cet avertissement et d’utiliser le code LLVM d’une manière qui n’a de sens que s’il reste stable. L’avenir nous dira comment cela évoluera.
La communauté scientifique pourrait définir sa propre représentation de code intermédiaire, en s’appuyant sur l’expérience des approches existantes et en optimisant sa plateforme pour les applications scientifiques. Mais, comme je l’ai dit plus haut, je ne suis pas optimiste quant à la réalisation de cela.
Deux conditions seraient nécessaires : un engagement à long terme de plusieurs grands organismes de recherche et de financement pour maintenir cette plateforme pendant plusieurs décennies. Je suis convaincu que cela serait économiquement raisonnable, car je suis certain que maintenir une seule plateforme coûte moins cher que de maintenir de nombreux packages logiciels scientifiques et de réécrire constamment ceux qui ne sont pas maintenus. Mais cela nécessiterait un niveau d’accord et d’engagement rare dans le milieu scientifique ; cela ne s’est produit que pour quelques installations énormes telles que le CERN .
L’avantage important offert par une plateforme stable est la raison pour laquelle la première édition d’ActivePapers a été conçue autour de la JVM. Malheureusement, la JVM n’est pas très populaire dans le calcul scientifique.
Cela s’explique souvent par un manque de performance, bien que cet argument ne soit plus aussi valable qu’autrefois. Il existe également quelques problèmes de conception, notamment concernant les opérations en virgule flottante, mais on peut en dire autant de langages populaires comme C ou C++, ce qui n’a pas empêché les scientifiques de les utiliser. L’édition Python d’ActivePapers, plus utile en pratique, est construite sur une plateforme définie par l’écosystème Scientific Python (en particulier Python, NumPy et h5py).
Cette plateforme s’est avérée modérément stable par le passé, la transition vers Python 3 étant le principal événement d’instabilité. L’échelle de temps sur laquelle les scientifiques
Pour aller plus loin
- SciPy — Wikipédia
L'étagère de référence pour les scientifiques en activité
Une bibliothèque technique approfondie de livres, de vidéos et de formations en informatique scientifique