Wie stelle ich Reproduzierbarkeit der von meiner Software produzierten Daten sicher?
Generell gibt es hierfür zwei Wege, die sich aber in letzter Konsequenz widersprechen. Einerseits die möglichst unveränderte Konservierung des Programmcodes. Bei diesem Vorgehen besteht praktisch keine Gefahr, dass sich die von der Software produzierten Daten ändern, allerdings ist die Ausführbarkeit auf lange Sicht nicht mehr garantiert. Der andere Weg wäre die kontinuierliche Pflege der Software, die zumindest Anpassungen an sich verändernde Betriebssysteme und Laufzeitumgebungen erfordert; idealerweise ist hiermit auch eine Weiterentwicklung verbunden.
Konservierung des Programmcodes
Dieses Vorgehen kann unter Umständen auch zu Dokumentationszwecken erforderlich sein (z.B. wenn die Software Teil einer Veröffentlichung ist).
Archivieren
- Container (Docker incl. Docker Hub, podman): Programmieren sollte von Anfang an im Hinblick auf Verwendung des Containers erfolgen, Anpassung bereits fertiger Software kann schwierig sein
- VM: funktioniert auch weitgehend problemlos mit vorhandener Software, Möglichkeit, gemeinsam mit der Software auch (alte) Betriebssysteme zu konservieren
- Verlässlichkeit auf lange Zeit hängt auch von der Existenz von Unternehmen ab (z.B. Docker)
- Was ist wenn Pakete, die z.B. ins Basisimage nachinstalliert werden müssen, nicht mehr verfügbar sind? -> Sollte zumindest bei Docker garantiert sein.
- Weitere Infos in Konrad Hinsens Blog:
- Zwei (relativ alte - warum gibt es hier nichts Neueres?) Artikel zum Thema Konservierung von Software incl. Betriebssystem:
Wie stelle ich sicher, dass mein Quellcode 10 Jahre lang lesbar (und ausführbar) bleibt?
- TECHNOLOGY FEATURE: Challenge to scientists: does your ten-year-old code still run?
- Anwendungskonservierung des Humanities Data Centre (Göttingen)
- Beispiele umfassen ein Software-Projekt des MPI-MMG (die PIDs sind leider nicht mehr gültig)
- Sicherstellen, dass Datenformate auch in Zukunft lesbar bleiben werden (Are Research Datasets FAIR in the Long Run?)
- Siehe hierzu auch im Pad FAQs zu PIDs und Zitation: Wie wird Software persistent?
Kontinuierliche Pflege
Hierfür ist Reviewing, konsequentes Testen (auch automatisiert) und Dokumentation (auch in Form einer Versionsverwaltung) unbedingt erforderlich.
Welche Standards gibt es für das Reviewing wissenschaftlicher Software (fachspezifisch oder generisch)
- Pair-programming
- KI (Co-piloting)?
- JOSS Reviewer Guidelines
Beispiele
- MPI Psychiatrie Code Club = lokale Lösung!
- Code review checklist vom MPI Psychiatrie Code Club
- INRIA software self assesment
- MaRDI TA1 technical review sheet (math, besserer Link TODO)
- ADHO DHTech Code Review
Konsequentes Testen
Wie lassen sich Regressionstests automatisieren?
Drei Bewertungen entsprechender Software (https://www.rainforestqa.com/blog/regression-testing-tools, https://www.softwaretestinghelp.com/regression-testing-tools/, https://theqalead.com/tools/best-regression-testing-tools/). Als Schnittmenge ergibt sich (in alphabetischer Reihenfolge):
- IBM Rational Functional Tester
- Katalon Studio
- Selenium
- Watir
- In den Bewertungen nicht enthalten: KD-Executor
Bisher ist nichts davon über die Lizenzliste der MPDL (SoLi) verfügbar, evtl. Vorschläge einreichen
In jedem Fall unabdingbar: Dokumentation (Software und Hardware!)
- in letzter Konsequenz bleibt nur die textbasierte Dokumentation des Algorithmus, unabhängig von der Programmierasprache (wäre aber extrem aufwändig)
- Kompromiss: Quellcode inklusive aller relevanten Bibliotheken ebenfalls als Quellcode (vor allem bei mathematischen Berechnungen)
- Bezüglich Dokumentationstools für Software siehe auch die FAQ zu Dokumentation.