Der Softwaremanagementplan

(Forschungs-)Software effizient managen

Ein Softwaremanagementplan (SMP) beinhaltet allgemeine und technische Informationen zum Softwareprojekt, Angaben zur Qualitätssicherung, zum Release und zur öffentlichen Verfügbarkeit sowie rechtliche und ethische Aspekte, die die Software betreffen.

Der SMP fasst Informationen zusammen, die die Erstellung, Dokumentation, Speicherung, Versionierung, Lizenzierung, Archivierung und/oder Veröffentlichung der in einem Projekt erzeugten oder verwendeten Software hinreichend beschreiben und dokumentieren. Dazugehörige Hardware und notwendige andere Ressourcen, aber auch damit verbundene weitere Software und Softwarebibliotheken, Text- und Datenpublikationen sind ebenfalls zu beschreiben und stellen eine Besonderheit des SMP dar.

Zweck eines SMPs ist zunächst die Nachvollziehbarkeit sowie ggf. die langfristige Nutzbarkeit der Software (zur direkten Anwendung sowie zur Weiterverarbeitung) zu unterstützen und den Support der Nutzer:innen bei Rückfragen zu erleichtern. Der SMP dient folglich auch der Qualitätssicherung (vgl. hierzu FAIR4RS Principles).

Der SMP kann in Verbindung zu einem oder mehreren Datenmanagementplänen (DMP) stehen, falls die Software zur Datengenerierung oder -verarbeitung genutzt wird. SMP und DMP können als Output-Pläne zusammengefasst werden (vgl. Software Sustainability Institute).

Die Inhalte eines Softwaremanagementplans können je nach Projekt variieren, umfassen in der Regel aber folgende Abschnitte:

Bestandteile eines Softwaremangementplans im Überblick

Projektname, Projektbeteiligte, Zeitplan, Finanzierung/Förderer, benötigte Hardware, Entwicklungsumgebung

Funktion und Anwendung, Code, externe Komponenten und Bibliotheken, Zielgruppe, Einsatz

Dokumentation für Benutzer und Admins/Nachprogrammierer (inline oder gesondert) bzgl. Methoden, Schnittstellen, Versionierung (Release Management), Metadaten, Testen sowie Qualitätssicherung/-standards

Archivierung und Veröffentlichung der Software, Lizenzen / Nutzungsrechte

Langfristige Betreuung der Software, Unterstützung der Nutzenden

Urheberrecht, Dual Use, Ethikprüfung

potenzielle Nachnutzung der Software, Mehrwert für die Wissenschaft

Ressourcen (Personal, Hardware, Software, Training) und Rollen

Der Nutzen eines Softwaremanagementplans

Vorteile des SMP gegenüber DMP

  • Höheres Verständnis der Software-Entwicklung als kooperatives Projekt
  • Höheres Produktzentrierung der Software-Entwicklung

Homogenisierung der Software

  • Vergleichbarkeit
  • Nachnutzung von Software-Modulen
  • Verbreitung guter Kodierungspraktiken

Mehrwert für die Forschung (Element)

  • Nachvollziehbarkeit
  • Nachnutzbarkeit

Qualitätssicherung

  • Ergänzt/verbessert Dokumentation zugunsten eines Peer Review und zur Nachnutzung
  • Ermöglicht frühzeitige Prüfung der Software- und Hardwarekomponenten
  • Einhaltung der FAIR4RS Principles

Beratung

  • Hintergrundinformationen
  • Frühzeitige Erkennung von Schwachstellen (geplante Verwendung proprietärer oder fragewürdiger Bibliotheken...)
  • Kostenkontrolle

Kostenfrei SMPs erstellen

Softwaremanagementpläne können in den kostenfreien DMP-Tools DMPonline und RDMO anhand eines speziellen Templates bzw. Fragenkatalogs erstellt werden. Darüber hinaus existiert ein DOCX- und Markdown-Template des Software Sustainability Institutes. Für die Erstellung eines SMP eignet sich des Weiteren ein GitHub- oder GitLab-Wiki, um Planung und Umsetzung in einer Anwendung zu dokumentieren.

Anforderungen der Forschungsförderer an Forschungssoftware

Deutsche Forschungsgemeinschaft (DFG)

  • SMP ist nicht notwendig
  • Kodex Leitlinie 13 „Herstellung von öffentlichem Zugang zu Forschungsergebnissen“: „die eingesetzte Software verfügbar zu machen und Arbeitsabläufe umfänglich darzulegen. Selbst programmierte Software wird unter Angabe des Quellcodes öffentlich zugänglich gemacht.“

European Research Council (ERC)

Horizon Europe

  • SMP ist nicht notwendig
  • Software wird im General Model Grant Agreement (v1.1) kaum explizit erwähnt
  • aber: „the beneficiaries must provide (digital or physical) access to data or other results needed for validation of the conclusions of scientific publications, to the extent that their legitimate interests or constraints are safeguarded“ S. 112

VolkswagenStiftung

  • SMP ist nicht notwendig
  • aber Software findet Erwähnung in der Open Science-Policy:
  • „Software [ist] kein ,Beiprodukt‘, sondern integraler Bestandteil von Forschung“ S. 5
  • „Antragstellung ist im CV des Antragstellenden Open-Source-Software gesondert für den Begutachtungs- und Entscheidungsprozess auszuweisen.“ S. 6

Bundesministerium für Bildung und Forschung (BMBF)

  • keine dezidierten Anforderungen zu Software

Softwaremanagementplan-FAQ

Wann ist ein SMP notwendig? Welche Projektgröße erfordert einen SMP?

Ein SMP ist nicht immer zwingend erforderlich oder notwendig. Zunächst sollten die Anforderungen des Forschungsförderers geprüft werden. Je nach Projektumfang kann es aber sehr sinnvoll sein, einen Softwaremanagementplan zu verfassen und kontinuierlich zu pflegen, z. B. wenn die Software der primäre Projektoutput ist. Als Leitfaden kann die Klassifikation des DLR dienen (siehe S.7): Anwendungsklassen 0-1 - kein SMP, Anwendungsklassen 2-3 - SMP empfohlen.

Gibt es Vorlagen zum Schreiben von Softwaremanagementplänen?

Ja, verschiedene Institutionen und Communities bieten mittlerweile SMP-Vorlagen an, z.B. RDMO oder Elixir. Interessant ist hierbei auch die SMP-Handreichung aus den Niederlanden.

Wie verfasst man einen realistischen SMP und wie setzt man einen SMP um?

Ein SMP sollte möglichst realistisch formuliert sein und keine Versprechungen machen, die nicht eingehalten werden können. Ein Konsens in der Projektgruppe ist daher anzustreben. Die Verwendung von Templates ist empfehlenswert, um relevante Themen zu prüfen. Die Umsetzung des SMP sollte analog zum DMP von regelmäßigen Aktualisierungen begleitet werden, um Veränderungen sichtbar zu machen (SMP als Living Document).

Welches Ticketsystem wird empfohlen?

Die Auswahl des Ticketsystems hängt vom Umfang des Projekts ab. Es existieren sowohl eigenständige Lösungen als auch integrierte Ticketsysteme in größeren Software-Paketen. Mit dem Fokus auf die Software-Entwicklung bieten GitLab und GitHub bereits passende Ticketsysteme an, die mit Schritten bei der Software-Entwicklung verknüpft werden können.

Welches Versionierungssystem wird empfohlen?

Die Versionierung bei der Arbeit mit Softwarecode ist ratsam. Für die Versionierung bieten sich Software-Lösungen wie GitLab, GitHub, Codeberg, BitBucket etc. an. Häufig werden diese bereits von der eigenen Institution oder als föderierte Infrastruktur angeboten.

Welches Repositorium kann man zum Veröffentlichen von Forschungssoftware verwenden?

Je nach Anwendungsfall kann die Software offen beispielsweise über GitLab, GitHub, Codeberg, CodeOcean oder BitBucket zugänglich gemacht werden. Datenrepositorien können sich auch für die Veröffentlichung von Forschungssoftware eignen. Teilweise existieren schon geeignete Schnittstellen, sodass beispielsweise über eine GitHub Action automatisch ein neuer Release auf Zenodo veröffentlicht werden kann.

Literatur

Papier: „Sicherstellung der Reproduzierbarkeit von Forschungsergebnissen durch Bewahrung des Zugriffs auf Forschungssoftware“
Autorinnen: Dirk von Suchodoletz, Peter Brettschneider, Alexandra Axtmann, Maximilian Heber, Lars Oberländer, Jan Leendertse, Irene Schumm, Olaf Brand, Karstin Schmidt, Livia Gertis, Michael Selzer, Robert Ulrich, Dorothea Iglezakis, Valerie Boda
Erscheinungsjahr: 2023
Link zum Papier

Dieser Text wurde in Zusammenarbeit mit der UAG-DMP der DINI/nestor-AG Forschungsdaten erstellt.