PODLIST

Research Software Engineering

Download

Vom 30. Mai - 2. Juni 2019 fand im ZKM und in der Hochschule für Gestaltung (HfG) die GPN19 statt. Dort traf Sebastian auf Carina Haupt, die schon auf der GPN18 von der öffentlich finanzierten Wissenschaft forderte: Publish Your Research!


Carina Haupt studierte Informatik an der Hochschule Bonn-Rhein-Sieg. Aktuell befasst Sie sich wissenschaftlich mit Forschungssoftware, die meist von Wissenschaftlerinnen und Wissenschaftlern nur geringfügiger Kenntnis von Softwaretechnik oder unter Aspekten von Nachhaltigkeit entwickelt wird, da die Software nur als Mittel zum Zweck gesehen wird. Ziel der Wissenschaftlerinnen und Wissenschaftlern ist es schließlich Forschung zu betreiben und nicht Software zu entwickeln.

Dabei zeigt die anhaltende Replication Crisis, die darin besteht, dass etliche publizierte wissenschaftliche Arbeiten nicht reproduzierbar sind, und somit alle abgeleiteten Arbeiten auf unsicheren Füßen stehen und eigentlich unter den geänderten Voraussetzungen wiederholt werden müssten.

Eine Herausforderung ist, dass für viele Forschende, wie beispielsweise in der Mathematik, oft die Software nur zur Verifikation der eigentlichen wissenschaftlichen Aussagen verwendet wird, und daher eine deutlich geringere Wertschätzung erfährt. Auch wird ein Reputationsverlust befürchtet, wenn die Softwarequalität nicht den Ansprüchen im Kernbereich der Forschung entspricht, so dass oft von einer veröffentlichung des Source Codes und der Daten abgesehen wird. Dabei muss die Offenlegung der verwendeten Verfahren und Daten ein Grundanliegen ernsthafter Forschung sein und eine Kennzeichnung von Software beispielsweise als Proof-of-Concept sollte einen angemessenen Anspruch an die Software sicherstellen.

Am Deutschen Zentrum für Luft- und Raumfahrt (DLR), leitet Carina eine Gruppe zum Software Engineering und ist dort mit ihren Kolleginnen und Kollegen für 40 Institute an 20 Standorten Ansprech- und Kooperationspartnerin für Softwareentwicklung unter anderem im wissenschaftlichen Umfeld von Luft- und Raumfahrt, Energie und Verkehr. Inzwischen ist dort ihr Enthusiasmus für Open Source, und Forschenden in der Softwareentwicklung zu unterstützen, zu ihrem eigenen Forschungsgebiet geworden.

Bevor sie zum DLR kam, war sie beim Fraunhofer-Institut für Algorithmen und Wissenschaftliches Rechnen (SCAI) im Bereich der Bioinformatik und dem Semantic Web, sowie in der Industrie und nebenberuflich bei der Froscon tätig, bis sie dem Ruf von Andreas Schreiber in ihre aktuelle Gruppe folgte.

Um Außenstehenden einen schnellen und sehr unterhaltsamen Einstieg in und wichtige Motivation für das Software Engineering bei der DLR zu bieten, hat sie auf der GPN18 einen Vortrag Software-Fehler in der Raumfahrt: Disintegrating Rockets mit großem Anklang gehalten.


Aber kann die Publikation von Forschungsdaten bei Auswirkungen der Replikationskrise wie der Analyse, dass über die Hälfte von Psychologiepapern nicht nachvollzogen werden können, helfen? Auf jeden Fall hätte die Veröffentlichung schon frühere Diskussionen und Verbesserungen der Ergebnisse ermöglicht, da abgeleitete Arbeiten statt der geschriebenen Darstellung auf den echten Daten ihre erweiterten Analysen hätten durchführen können.

Soweit die Theorie, praktisch muss man sich eingehend damit befassen, was genau erforderlich ist, um eine Reproduzierbarkeit schon auf Seiten der Daten und Software zu ermöglichen. Das Befassen mit diesen Themen führt von einer Erstellung einer Publikation zum Begriff der Open Science oder offener Wissenschaft, die unter anderem Open Access, Open Data als auch Open Source betrifft. Hier konzentriert sich Carina in ihrer Forschung besonders auf den letzten Teil, insbesondere wie Erkenntnisse aus der Softwaretechnik dazu beitragen können, dem großen Ziel der Reproduzierbarkeit auch über die Zeit hinweg zumindest näher zu kommen.

Wichtig ist auch den Entstehensprozess von Software zu betrachten. Die Fernseh-Show Bares für Rares demonstriert, wie die Wertigkeit eines Objekts durch eine nachgewiesene Herkunft signifikant beeinflusst wird. Dies erfolgt durch Nachweis der sogenannten Provenience. Der Begriff Provenience bedeutet die Aufzeichnung der Geschichte der Entstehung eines Objektes. Dies läßt sich auf Software übertragen. Die Wertigkeit und Qualität von einer Software-Publikation könnte zum Beispiel dadruch evaluiert werden indem der Build- und Entwicklungsprozess aufgezeichnet, und mit dem PROV W3C-Standards dokumentiert.

Neben der Dokumentation liegt der nächste Schritt für reproduzierbare Software (vgl. E. Heitlinger: Reproduzierbarkeit – Wissenschaftliche Arbeit als Software-Projekt) darin, die erforderlichen zusätzlichen Bestandteile auch zur Verfügung zu stellen. Die nachhaltige Softwareentwicklung befasst sich in besonderem Maße damit, dass die Software von anderen sowohl genutzt als auch in Zukunft weiterentwickelt werden kann. Natürlich sollten wissenschaftliche Veröffentlichungen grundsätzlich die Wissensgewinnung und Validierung genau beschreiben, nur ist dies im gängigen Rahmen und Form normaler Publikationsformen weder in Form noch im Umfang abzubilden. Daher fordern viele Journals und Konferenzen, die Daten und Methoden in der Form von ausführbaren, web-basierten Jupyter Notebooks zur Verfügung zu stellen.

Ein neuer Ansatz ist eine "Software Zitierbarkeit" zu ermöglichen, also sowohl die Form mit Weblinks und Versionierung, also auch mit Infrastruktur wie dem Dienst Zenodo, das einen Digital Object Indentifier (DOI) für Software mit einem Langzeitarchiv bereitstellt. Das ist ein Service, der in etwas weniger spezialisierter Form für unterschiedliche Medien auch von vielen Hochschulbibliotheken angeboten wird.

Am DLR widmet sich die Software Engineering Initiative mit vielen Ansätzen, um Forschenden zu helfen nachhaltige Software zu entwickeln. Ein wichtiger Bestandteil sind hier Trainings, wie beispielsweise Repositories verwendet werden sollten:

  1. Hinweise für sinnvolle Commit-Messages verwenden.
  2. Wie sollten Versionen vergeben werden?
  3. Neben den eigentlichen Sourcen sollte auch der Build-Prozess und Testdaten im Repository sein
  4. Sinnvolle Struktur von Dateibäumen und sprechende Bennenung von Dateien
  5. Jedes Repository sollte eine README-Datei haben, die am Anfang kurz die Funktion der Sourcen beschreibt und in welchem Scope und in welchen Constraints die Ziele erreicht werden sollen, wie sie installiert, ausgeführt und getestet wird und wie sollte die Software zitiert werden?
  6. Unter welcher Lizenz steht die Software?

Unterstützung gibt es auch durch zentrale Infrastruktur, die vom DLR beispielsweise durch eine eigene GitLab bald zur Verfügung stehen wird, und allen Forschenden einen eigenen persönlichen Bereich anbieten, sowie Projekten sofort entsprechende Strukturen bereitstellen.

Die im Gespräch erwähnte SHA1-Kollision Shattered hatte einen Stillstand der für mehrere Browser grundlegende WebKit-Entwicklung zur Folge, da deren Subversion-Repository nicht mit der Hash-Kollision zurecht gekommen ist.

Es gibt vielseitige Motivationsgründe für Forschende die Unterstützung der Software Engineering Initiative anzunehmen: Entweder sind sie aus einem füngeren universitären Umfeld schon mit der Thematik vertraut, oder haben Probleme durch fehlene Softwarequalität schon kennengelernt, lassen sich von Beispielen überzeugen oder Qualitätsanforderungen überreden, oder es wird ihnen durch Vorgesetzte nahe gelegt.

Ein Mittel zur Motivation sind insbesondere die am DLR entwickelten Software Engineering Guidelines, die Kolleginnen und Kollegen zur Verfügung gestellt werden können. Darin sind sowohl Begründungen für das Vorgehen, aber auch einfach zur verfolgende Entscheidungsbäume und Checklisten, die je nach Größe und Kritikalität von Projekt unterschiedlich aufwendige Empfehlungen vorschlagen. Dies kann von einer TODO-Datei bis zur Integration eines vollständigen Issue-Tracker gehen, der in der höchsten Qualitätsstufe auch mit dem kompletten Code-Management integriert werden sollte. Diese Guidelines sind am DLR in eine Qualitätsinitiative integriert, bei der in jedem Institut ein Qualitätsbeauftragter oder eine Qualitätsbeauftragte zumindest erfassen sollte, warum bestimmte Empfehlungen nicht entsprochen wird, oder idealerweise das Institut dabei dazu zu motivieren diese einfach genau so umsetzen.

Die erforderliche Bereitstellung digitaler Infrastruktur durch Organisationen spielt für Hochschulen neben den Bereichen des Software Engineerings auch in der Lehre eine wichtige Rolle:

"Wenn technische Möglichkeiten wie Vorlesungsaufzeichnungen auch im Rahmen obligatorischer Lehrveranstaltungen genutzt werden sollen, müssen Hochschulen daher auch aus datenschutzrechtlichen Gründen entweder eine eigene Infrastruktur aufbauen oder datenschutzkonforme Dienstleistungen gegen Entgelt in Anspruch nehmen."
A. Lauber-Rönsberg in Videocampus Sachsen – Machbarkeitsuntersuchung.

Was alles bei der Nutzung mit Software-Repositories am Beispiel von GIT passieren kann, erzählt Sujeevan Vijayakumaran im GPN19-Vortrag Dämliche Dinge mit git anstellen.


Grundlage für viele Aktivitäten der Software Engineering Group basieren auf Software Carpentries, beispielsweise mit einer GIT Einführung, die auch auf die Nachhaltigkeit abzielt.

In der Helmholtz-Gesellschaft wurde das HIFIS-Projekt (Helmholtz Infrastructure for Federated ICT Services) gestartet, um die Initiativen und Erfahrungen in der Bereitstellung von Infrastrukturen innerhalb der Helmholtz Gesellschaft zu bündeln. Hier geht es nicht nur um den Betrieb der Software, sondern auch um das Training für die Services und im Allgemeinen. Dazu sollen Communities für Software Engineering und weiteren Themen gebildet werden, damit der Austausch über Erfahrungen und Wissen leichter ablaufen kann.

Die Initiativen im Bereich der Research Software Engineers werden im neu gegründeten Verein DE-RSE e.V. gegründet, der vom 4.-6. Juni im Potsdam die erste
Konferenz für ForschungssoftwareentwicklerInnen in Deutschland deRSE19 veranstaltet. Der Ursprung dieser Initiative liegt im WSSSPE Workshop (Working towards sustainable software for science: practice and experiences) und der Konferenz der Research Software Egineers Association. Die #deRSE19 wird auch besonders durch die TIB, dem Leibniz-Informationszentrum, Technik und Naturwissenschaften, Universitätsbibliothek, unterstützt.

In der Zukunft muss es auch darum gehen, Infrastrukturen bereit zu stellen, über gute Verfahren zu informieren und auch Anreize für Forschenden zu schaffen, die verschiedenen Ansätze aufnehmen. Der Verein und das HIFIS-Projekt möchten hier mit unterschiedlichen Ansätzen dazu beitragen die Situation zu verbessern, und insbesondere die aktuelle Dynamik in Richtung Open Journals, Open Data, Open Source und Open Science zu nutzen.

Für einzelne Gruppen und Instituten sollte die Wichtigkeit sich mit Open Source Lizenzen nicht unterschätzt werden: Es kann sonst zu Inkopatibilitäten zwischen verschiedenen Lizenzen kommen, oder es fehlen Einverständniserklärungen von einzelnen, nicht vertraglich verbundenen Personen. Diese können beispielsweise Studierende sein, die im Rahmen einer Abschlussarbeit an einem Projekt mitgearbeitet haben. Hier muss ein Contributor Licence Agreement bereit sein, die von sonst nicht vertraglich gebunden Beitragenden unterschrieben werden kann.




Literatur und weiterführende Informationen



Podcasts





GPN19 Special


GPN18 Special


GPN17 Special


GPN16 Special