Softwareentwicklung in der Wissenschaft
Eine Handreichung zur Umsetzung der Leitlinien zur Sicherung guter wissenschaftlichen Praxis der DFG
Eine sorgsame Softwareentwicklung ist essentieller Bestandteil Guter Wissenschaftlicher Praxis. Die Leitlinien der Deutschen Forschungsgemeinschaft zur guten wissenschaftlichen Praxis beziehen sich deshalb auch auf Forschungssoftware. Sie begründen Mindeststandards und Verhaltensweisen. Doch wie lässt sich dies umsetzen? Ein Vorschlag für die Realisierung.
Die folgende Tabelle gibt einen Überblick über die wichtigsten Punkte aus dem Kodex der DFG, die sich auf softwarespezifische Aspekte beziehen.
| Aus dem Kodex “Leitlinien zur Sicherung guter wissenschaftlicher Praxis” (Stand: 04/2022) | Anmerkung |
| “Grundsätzlich bringen Wissenschaftlerinnen und Wissenschaftler alle Ergebnisse in den wissenschaftlichen Diskurs ein.” (Leitlinie 13) | Ausnahmen darf es in begründeten Einzelfällen geben. |
| “Selbst programmierte Software wird unter Angabe des Quellcodes öffentlich zugänglich gemacht.” | Die Möglichkeit einer angemessenen Embargofrist kann genutzt werden. |
| “Der Quellcode von öffentlich zugänglicher Software muss persistent, zitierbar und dokumentiert sein.” (Erläuterung zur Leitlinie 7) | Alles andere gilt nicht als erfolgereich öffentlich zugänglich gemacht. |
| “Bei der Entwicklung von Forschungssoftware wird der Quellcode dokumentiert.” (Leitlinie 12) | Die Dokumentation soll immer erfolgen, selbst wenn keine Veröffentlichung geplant ist. |
Umsetzungsempfehlungen
Forschungssoftware ist ein integraler Teil des Forschungsprozesses und in vielen Fällen unabdingbar für die Nachvollziehbarkeit von Forschungsergebnissen und -daten. Die eingesetzte Software kann selbst Teil der Ergebnisse sein und sollte dann zu einem geeigneten Zeitpunkt und in geeigneter Form in den wissenschaftlichen Diskurs einfließen.
Forschungssoftware umfasst im weiteren Sinne auch Befehlseingaben über die Kommandozeile. Um eine lückenlose Nachvollziehbarkeit der getätigten Arbeitsabläufe zu ermöglichen, kann beispielsweise ein Befehl zur Steuerung von Software publikationswürdig sein, wenn darin Fachwissen enthalten ist.
1. Versionierung
Software wird versioniert. Wenn ein wissenschaftliches Ergebnis erzeugt wurde, wird die benutzte Version benannt und diese archiviert. Das Stadium der Software wird geeignet kenntlich gemacht. Auch wenn Software im Forschungsumfeld agil entwickelt wird und sich innerhalb eines Tages die Erwartungshaltung an sie ändern kann, können grob drei Reifegrade voneinander unterschieden werden. Diese zeigt die folgende Abbildung.
| Status | Beschreibung | Versionsnummern |
| 0 | Hier wird nicht angestrebt, einen (ineffizienten) “Proof-of-Principle-Prototypen” auf ein stabiles, professionell getestetes und allgemein verwendbares Niveau zu heben, weil die Software ihre (einmalige) Aufgabe erfüllt hat. Das sollte kenntlich gemacht werden. Am besten durch einen Hinweis über dem Quellcode und einer sehr niedrigen Versionsnummer | 0.0x |
| 1 | Es ist noch kein abgeschlossener Funktionsumfang erreicht, aber die Software funktioniert mutmaßlich auch über die anfänglichen Anwendungsbeispiele hinaus stabil und die Programmstruktur ist zur einfachen Fortentwicklung geeignet. | ≥0.1 und <1.0 |
| 2 | Für die Software existieren einigermaßen umfangreiche Testbeispiele und eine eigene Dokumentation. Ein Produktivbetrieb ist möglich. | ≥1.0 |
2. Dokumentation
Software ist geeignet zu kommentieren und ggf. zu dokumentieren, selbst wenn keine Veröffentlichung geplant ist. Forschungssoftware muss für den Leser nachvollziehbar dokumentiert sein. Für eine agile Arbeitspraxis können drei Stufen der Ausführlichkeit der Dokumentation voneinander abgegrenzt werden.
| Dokumentationsart | Beschreibung |
| Minimaldokumentation | Programm- und Funktionsnamen und andere Hinweis erklären abstrakt, was der Zweck ist und wie das Programm ggf. zu benutzen ist. Das kann knapp sein, sollte aber die Intention jedes Programmteils so erfassen, dass entschieden werden kann, ob ein Teil korrekt funktioniert. |
| Normaldokumentation | Es werden Best Practices angewendet (beispielsweise c++ core guidelines oder pythons pep8). |
| Volldokumentation | Software im Produktivbetrieb sollte eine eigenständige Dokumentation besitzen, die sowohl eine technische Dokumentation als auch eine Kurzanleitung umfasst. |
3. Publikation
Eine wissenschaftliche Publikation in einem Fachjournal muss die notwendigen Informationen für den wissenschaftlichen Diskurs zur Verfügung stellen. Wurde bei der Erstellung der Publikation Forschungssoftware verwendet, sollte diese möglichst mit Versionsnummer (falls vorhanden auch durch eine PID, z. B. DOI) zitiert werden. Der Zugang zu Forschungssoftware sollte, unter Beachtung von Punkt 1 und 2, frei zugänglich sein. Zur besseren Zitierbarkeit sind versionskontrollierte Softwarearchive zu bevorzugen. Wird ein freier Zugang zu der Software nicht zeitnah möglich, so ist zumindest der darin verwendete Algorithmus in seiner Funktion vollständig zu publizieren. In diesen Fällen muss geprüft werden, ob eine Freigabe der Softwarequellen innerhalb einer Embargofrist möglich ist. Sofern der Zugriff auf die Forschungssoftware nur eingeschränkt möglich ist, muss dies unter Angabe des Grunds und ggf. der Embargofrist auch nach außen hin transparent dargelegt werden. Ein zulässiger Grund ist der Schutz von (geistigem) Eigentum z. B. an werthaltigen, nicht im engeren Sinn wissenschaftlichen Komponenten vor einer Veröffentlichung.
4. Empfehlungen (Checkliste)
- einen Softwarequalitätskurs besuchen
- Prüfsoftware für Quellcode einsatzbereit haben
- den Zweck der Software kurz und bündig formulieren
- den Reifegrad der Software passend zur aktuellen Vorgehensweise der Qualitätssicherung halten
- die Intention jeder Funktion erkennbar machen (etwa durch selbsterklärende Namen oder Kommentare)
- eine zulässige Lizenz wählen
Die Erstellung dieses Textes wurde mit einer Förderung durch die Deutsche Forschungsgemeinschaft (DFG) im Rahmen der Exzellenzstrategie des Bundes und der Länder – 2082/1 – 390761711 unterstützt.