{"id":832,"date":"2026-07-30T12:22:29","date_gmt":"2026-07-30T12:22:29","guid":{"rendered":"https:\/\/matforge.org\/?p=832","raw":"https:\/\/matforge.org\/?p=832"},"modified":"2026-07-30T12:22:29","modified_gmt":"2026-07-30T12:22:29","slug":"versioning-reproducibility-and-why-research-software-teams-face-integrity-issues-too","status":"publish","type":"post","link":"https:\/\/matforge.org\/de\/versioning-reproducibility-and-why-research-software-teams-face-integrity-issues-too\/","title":{"rendered":"Versionierung, Reproduzierbarkeit und warum auch Forschungssoftware-Teams Integrit\u00e4tsprobleme haben","raw":"Versionierung, Reproduzierbarkeit und warum auch Forschungssoftware-Teams Integrit\u00e4tsprobleme haben"},"content":{"rendered":"Reading Time: <\/span> 6<\/span> minutes<\/span><\/span>

Die Integrit\u00e4tsfrage beginnt nicht mit der Ver\u00f6ffentlichung<\/h2>\n

Die Forschungsintegrit\u00e4t in der softwarelastigen Wissenschaft beginnt lange bevor ein Manuskript eingereicht wird. In Materialsimulation, Rechenmodellierung und Forschungsrechenworkflows ist die ver\u00f6ffentlichte Behauptung oft nur die endg\u00fcltige Oberfl\u00e4che einer viel l\u00e4ngeren Kette: Code, Konfiguration, Abh\u00e4ngigkeitsversionen, Eingabedaten, Solververhalten, Laufhistorie und Interpretation.<\/p>\n

Diese Kette kann leise schw\u00e4cher werden. Eine Figur kann aus einem sp\u00e4ter ge\u00e4nderten Skript stammen. Eine Simulation kann von einer lokalen Umgebung abh\u00e4ngen, die sonst niemand neu erstellen kann. Ein Notebook kann die endg\u00fcltige Ausgabe enthalten, aber nicht die genaue Reihenfolge, die es erzeugt hat. Eine Parameterdatei wurde m\u00f6glicherweise bearbeitet, nachdem das Ergebnis zum ersten Mal besprochen wurde. Keine dieser Situationen beweist automatisch Fehlverhalten, aber jede macht die Forschung schwieriger zu \u00fcberpr\u00fcfen.<\/p>\n

F\u00fcr Forschungssoftwareteams geht es bei Integrit\u00e4t nicht nur darum, kopierten Text oder erfundene Daten zu vermeiden. Es geht auch darum, gen\u00fcgend Workflow-Beweise zu erhalten, um eine praktische Frage zu beantworten: Kann das Team erkl\u00e4ren, wie dieses Rechenergebnis entstanden ist?<\/p>\n

Versionskontrolle ist Beweis, nicht nur Organisation<\/h2>\n

Die Versionskontrolle wird h\u00e4ufig als eine M\u00f6glichkeit eingef\u00fchrt, um die Zusammenarbeit zu organisieren. Das ist wahr, aber unvollst\u00e4ndig. In der Forschungssoftware werden auch Commits, Verzweigungen, Tags, Releases und \u00c4nderungshistorien belegt. Sie zeigen, wann der Code ge\u00e4ndert wurde, wer ihn ge\u00e4ndert hat, was die \u00c4nderung ansprechen sollte und welcher Softwarestatus ein gemeldetes Ergebnis unterst\u00fctzt.<\/p>\n

Dies ist wichtig, da wissenschaftliche Software selten statisch ist. Ein Solver kann verfeinert werden, eine Randbedingung kann korrigiert werden, ein Plotskript kann bereinigt werden oder eine Abh\u00e4ngigkeit kann das Verhalten zwischen Versionen \u00e4ndern. Ohne einen stabilen Versionsdatensatz kann ein Team wissen, dass ein Ergebnis \u201evom aktuellen Code\u201c war, aber dieser Satz wird nutzlos, sobald der aktuelle Code fortgesetzt wird.<\/p>\n

Das vertraute Ordnermuster von final_code, final_code_v2 und final_code_revised kann sich w\u00e4hrend einer Projektfrist harmlos anf\u00fchlen. Sp\u00e4ter wird es zu einem Problem der R\u00fcckverfolgbarkeit. Wenn ein Papier, ein Bericht oder ein Datensatz nicht an ein bestimmtes Commit oder eine Tag-Release gebunden werden kann, h\u00e4ngt das Ergebnis eher vom Speicher als vom Beweis ab.<\/p>\n

Eine gute Versionierung garantiert keine korrekte Wissenschaft. Es macht etwas engeres und wesentlicheres: Es h\u00e4lt die Rechenaufzeichnung inspizierbar.<\/p>\n

Reproduzierbarkeit l\u00e4sst Debuggen und Integrit\u00e4t \u00fcberlappen<\/h2>\n

Debuggen und Integrit\u00e4ts\u00fcberpr\u00fcfung beginnen oft mit unterschiedlichen Motiven, stellen jedoch verwandte Fragen. Das Debuggen fragt: „Was hat sich ge\u00e4ndert?“ Integrity Review fragt: „Was hat dieses Ergebnis hervorgebracht?“ Beide Fragen h\u00e4ngen von der Reproduzierbarkeit ab.<\/p>\n

Wenn eine Simulation nicht mehr mit einer fr\u00fcheren Figur \u00fcbereinstimmt, muss ein Team wissen, ob die Ursache eine Code\u00e4nderung, eine Parameteranpassung, eine Abh\u00e4ngigkeitsaktualisierung, eine Netzeinstellung, ein zuf\u00e4lliger Startwert oder ein undokumentierter manueller Schritt war. Dieselben Informationen sind von Bedeutung, wenn ein Rezensent, ein Mitarbeiter oder ein zuk\u00fcnftiger Benutzer sp\u00e4ter fragt, ob das gemeldete Ergebnis vertrauensw\u00fcrdig ist.<\/p>\n

Dies ist der Grund, warum die Reproduzierbarkeit als Teil des Debuggens wissenschaftlicher Software <\/a> nicht nur eine Entwicklerkomfort ist. Es ist Teil der Integrit\u00e4tsinfrastruktur eines Forschungsworkflows. Ein reproduzierbarer Workflow bietet Teams die M\u00f6glichkeit, Fehler zu diagnostizieren und Ergebnisse zu verteidigen, ohne sich nur auf Autorit\u00e4t zu verlassen.<\/p>\n

Die \u00dcberschneidung ist besonders wichtig in schnelllebigen Forschungsprojekten. Ein Team kann Fehler beheben, Alternativen untersuchen und Simulationen vor der Ver\u00f6ffentlichung mehrmals erneut ausf\u00fchren. Wenn diese \u00c4nderungen nicht nachverfolgbar sind, kann gew\u00f6hnliche Entwicklungsarbeiten sp\u00e4ter wie eine ungekl\u00e4rte L\u00fccke in der Beweiskette aussehen.<\/p>\n

Die Integrit\u00e4tskette der Forschungssoftware<\/h2>\n

Eine n\u00fctzliche Methode, um \u00fcber die Integrit\u00e4t der Forschungssoftware nachzudenken, ist nicht eine Liste isolierter Best Practices, sondern als Kette. Jeder Link verbindet einen wissenschaftlichen Anspruch mit dem Beweis des Workflows. Wenn ein Glied schwach ist, wird der gesamte Anspruch schwerer zu inspizieren.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Integrit\u00e4tskette Link<\/th>\nFrage beantwortet es<\/th>\nBeweisteams sollten erhalten bleiben<\/th>\n<\/tr>\n
Forschungsfrage<\/td>\nWelches Anspruch, Verhalten oder Modellergebnis wurde getestet?<\/td>\nExperimentiernotizen, Referenzen, Projektplan oder Analyseziel<\/td>\n<\/tr>\n
Code-Zustand<\/td>\nWelche genaue Softwareversion hat das Ergebnis hervorgebracht?<\/td>\nCommit-Hash, Release-Tag, Verzweigungsreferenz, Archivierter Snapshot<\/td>\n<\/tr>\n
Umwelt<\/td>\nWelche Rechenbedingungen beeinflussten die Ausf\u00fchrung?<\/td>\nAbh\u00e4ngigkeitsdateien, Containerrezept, Compilerdetails, Solverversionen<\/td>\n<\/tr>\n
Modellkonfiguration<\/td>\nWelche Parameter, Randbedingungen, Netzeinstellungen oder Eingaben wurden verwendet?<\/td>\nKonfigurationsdateien, Eingabedatens\u00e4tze, Parameterprotokolle, Ausf\u00fchren von Metadaten<\/td>\n<\/tr>\n
Ausf\u00fchrungsdatensatz<\/td>\nWann und wie wurde die Simulation oder Analyse durchgef\u00fchrt?<\/td>\nAusf\u00fchren von Protokollen, Notebook-Ausf\u00fchrungsreihenfolge, Job-Skripten, zuf\u00e4lligen Seeds<\/td>\n<\/tr>\n
Ausgangsverbindung<\/td>\nWelche Zahlen, Tabellen oder gemeldeten Werte stammen aus diesem Lauf?<\/td>\nAusgabeverzeichnisse, Skripte der Abbildungsgenerierung, Ergebnismanifeste<\/td>\n<\/tr>\n
Bewertungspfad<\/td>\nWelche \u00c4nderungen, Tickets, Korrekturen oder Diskussionen erkl\u00e4ren den Ergebnisverlauf?<\/td>\nAusgabe von Tracker-Eintr\u00e4gen, Pull-Anforderungen, \u00dcberpr\u00fcfungsnotizen, Fehlerberichten<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Die Kette hilft Teams dabei, zwischen einem unordentlichen Workflow und einer integrensensiblen Arbeitsablaufl\u00fccke zu unterscheiden. Eine fehlende Notiz kann unpraktisch sein. Eine fehlende Verbindung zwischen einer ver\u00f6ffentlichten Figur und dem Code-Zustand, der sie erzeugt hat, ist schwerwiegender, da sie die \u00dcberpr\u00fcfungsf\u00e4higkeit des Ergebnisses schw\u00e4cht.<\/p>\n

Warum Materialsimulation den Einsatz erh\u00f6ht<\/h2>\n

Die Materialsimulation kann besonders empfindlich auf kleine Workflow-\u00c4nderungen reagieren. Ein Phasenfeldmodell, ein PDE-Solver, eine Netzauswahl oder eine Randbedingung k\u00f6nnen das Verhalten eines Ergebnisses beeinflussen und wie es interpretiert werden soll. Selbst wenn der Code mathematisch angemessen ist, kann die Ausgabe von Details abh\u00e4ngen, die leicht zu verlieren sind, wenn der Workflow nicht diszipliniert ist.<\/p>\n

In FIPY-basierten Phasenfeldmodellierungs-Workflows<\/a> kann beispielsweise die Integrit\u00e4tskette Solver-Einstellungen, Rasteraufl\u00f6sung, Zeitschrittauswahl, Materialparameter, Initialisierungsannahmen und Nachbearbeitungsskripte. Wenn diese St\u00fccke nicht versioniert oder aufgezeichnet sind, kann ein sp\u00e4terer Rezensent die endg\u00fcltige Handlung sehen, aber nicht den Rechenpfad, der ihn bedeutungsvoll gemacht hat.<\/p>\n

Dies bedeutet nicht, dass jedes Simulationsprojekt einen Softwareprozess auf Unternehmensebene ben\u00f6tigt. Dies bedeutet, dass Materialsimulationsteams Konfigurations- und Ausf\u00fchrungsnachweise als Teil des Forschungsobjekts behandeln sollten. Das Modell ist nicht nur die Gleichungen. Es ist auch der implementierte, parametrisierte, ausgef\u00fchrte Workflow, der interpretierbare Ausgaben erzeugt.<\/p>\n

Je sensibler die Ausgabe ist, desto wichtiger ist es, diese Entscheidungen so zu bewahren, dass ein anderes Teammitglied \u00fcberpr\u00fcft werden kann.<\/p>\n

Issue Tracker sind Teil des Forschungsdatensatzes<\/h2>\n

Issue-Tracker werden oft als Projektmanagement-Tools behandelt, k\u00f6nnen aber auch in der Forschungssoftware Teil der wissenschaftlichen Aufzeichnung werden. Ein Fehlerbericht k\u00f6nnte erkl\u00e4ren, warum sich ein Ergebnis ge\u00e4ndert hat. Eine Feature-Anfrage kann angezeigt werden, wann eine neue Modellfunktion eingef\u00fchrt wurde. Ein Diskussionsthread kann klarstellen, warum ein Parameter angepasst wurde oder warum eine fr\u00fchere Ausgabe als unzuverl\u00e4ssig angesehen wurde.<\/p>\n

Dieser Kontext ist wichtig, weil sich der wissenschaftliche Code durch Unsicherheit entwickelt. Ein Ticket \u00fcber instabile Konvergenz, unerwartete Ausgabe, Abh\u00e4ngigkeits\u00e4nderungen oder falsche Nachbearbeitung kann f\u00fcr eine Figur, die sp\u00e4ter in einem Papier erscheint, direkt relevant sein.<\/p>\n

Ein Problemverlauf sollte nicht als Schuldprotokoll verwendet werden. Seine st\u00e4rkere Rolle ist erkl\u00e4rend. Es hilft zuk\u00fcnftigen Lesern, die Beziehung zwischen Softwareentwicklung und wissenschaftlicher Interpretation zu verstehen. Wenn ein Problem vor der Ver\u00f6ffentlichung behoben wurde, kann der Datensatz zeigen, wie. Wenn es offen blieb, kann das Team erkl\u00e4ren, ob es das gemeldete Ergebnis beeinflusst hat.<\/p>\n

Wenn Issue-Tracker von den Ausgaben getrennt werden, verlieren Teams eine wichtige Evidenzebene. Wenn Tickets, Commits und Ergebnisse verkn\u00fcpft sind, kann sich der Workflow klarer erkl\u00e4ren.<\/p>\n

Wenn Workflow-L\u00fccken Integrit\u00e4tsrisiken<\/h2>\n

Nicht jede Workflow-L\u00fccke ist ein Integrit\u00e4tsproblem. Forschungssoftware ist komplex und unvollst\u00e4ndige Dokumentation ist \u00fcblich. Das Risiko steigt, wenn fehlende Arbeitsabl\u00e4ufe ein Team daran hindern, Autorenschaft, Herkunft, Ergebnisgenerierung oder die Beziehung zwischen der Software und der ver\u00f6ffentlichten Behauptung zu erkl\u00e4ren.<\/p>\n

Beispiele hierf\u00fcr sind ein Manuskript, das ein Repository zitiert, aber kein mit Tags versehenes Release, ein Notebook, das nach dem Generieren bearbeitet wurde, ein kopiertes internes Skript mit unklarer Herkunft, ein Abh\u00e4ngigkeitsupdate, das die Ausgabe \u00e4ndert, ohne aufgezeichnet zu werden, oder Simulationsergebnisse, die getrennt von der Ausf\u00fchrungskonfiguration gespeichert sind, die sie erstellt hat.<\/p>\n

Dies sind nicht nur technische Unannehmlichkeiten. Sie k\u00f6nnen zu \u00dcberpr\u00fcfungsproblemen werden, da Redakteure, Mitarbeiter und Qualit\u00e4tssicherungssysteme m\u00f6glicherweise Integrit\u00e4tsrisiken auf Workflow-Ebene in Forschungssoftware <\/a> bewerten m\u00fcssen, wenn rechnergest\u00fctzte Beweise Teil der Forschungsaufzeichnung sind.<\/p>\n

Der wichtige Punkt ist die Verh\u00e4ltnism\u00e4\u00dfigkeit. Ein technischer QS-Prozess sollte nicht jede fehlende Datei als Fehlverhalten behandeln. Es sollte jedoch erkannt werden, wenn das Fehlen von R\u00fcckverfolgbarkeit ein Ergebnis schwierig macht, zuzuschreiben, zuzuordnen oder zu reproduzieren.<\/p>\n

Eine praktische R\u00fcckverfolgbarkeits-Checkliste f\u00fcr Forschungssoftware-Teams<\/h2>\n

Forschungssoftware-Teams ben\u00f6tigen keine perfekte Infrastruktur, um das Integrit\u00e4tsrisiko zu verringern. Sie ben\u00f6tigen eine Mindestmenge von Gewohnheiten, die Anspr\u00fcche mit Beweisen in Verbindung bringen.<\/p>\n