{"id":17956,"date":"2022-06-02T17:18:48","date_gmt":"2022-06-02T15:18:48","guid":{"rendered":"https:\/\/dhd-blog.org\/?p=17956"},"modified":"2024-02-13T15:09:13","modified_gmt":"2024-02-13T14:09:13","slug":"3-nfdi4culture-expertinnen-forum-nachhaltige-softwareentwicklung-beurteilung-von-forschungssoftware","status":"publish","type":"post","link":"https:\/\/dhd-blog.org\/?p=17956","title":{"rendered":"3. NFDI4Culture Expert:innen-Forum \u201eNachhaltige Softwareentwicklung\u201c: Beurteilung von Forschungssoftware"},"content":{"rendered":"\n

verfasst von: Aleksander Marcic, Daniel Jettka (ORCID<\/u><\/a>), Lisa Dieckmann (ORCID<\/u><\/a>), Daniel R\u00f6wenstrunk (ORCID<\/u><\/a>), Anne Ferger (ORCID<\/a>) und Franziska Fritzsche (ORCID<\/a>)<\/p>\n\n\n\n

Das NFDI4Culture Expert:innenforum zum Thema Nachhaltige Softwareentwicklung kam am 27. April 2022 zu seinem dritten virtuellen Treffen zusammen. Das Treffen wird in halbj\u00e4hrlichem Rhythmus organisiert vom Arbeitsbereich „Research Tools and Data Services“<\/a> des NFDI4Culture-Konsortiums. Die eingeladenen Expert:innen und NFDI4Culture-Mitarbeiter:innen diskutieren im Rahmen des Forums, wie das Thema der Nachhaltigkeit von Forschungssoftware vorangebracht und weiter etabliert werden kann.<\/p>\n\n\n\n

Im Fokus des dritten Treffens stand die Beurteilung von Forschungssoftware, speziell ging es einerseits um die Diskussion von Kriterien f\u00fcr Einreichungen im CKIT Rezensionsjournal<\/a> und zum anderen um die Frage, ob und in welcher Form die Nachhaltigkeit von Forschungssoftware im Rahmen von und durch NFDI4Culture zertifiziert werden soll.<\/p>\n\n\n\n

Kriterien f\u00fcr das CKIT Rezensionsjournal<\/strong><\/h2>\n\n\n\n

Zu Beginn gab Anne Klammt mit Erg\u00e4nzungen von Lisa Dieckmann und Daniel R\u00f6wenstrunk (als Initiator:innen und Herausgeber:innen, zusammen mit Maria Effinger und Fabian Offert) eine kurze Einf\u00fchrung zum CKIT Rezensionsjournal und dessen Motivation. Rahmen f\u00fcr die folgenden Diskussionen war die Kontextualisierung des Journals (inkl. der Kriterien f\u00fcr Einreichungen) im Umfeld weiterer NFDI4Culture Initiativen, wie der sich im Aufbau befindenden dom\u00e4nenspezifischen Registry f\u00fcr Forschungssoftware und Datendienste, der Beratungsangebote und der Guidelines zu nachhaltiger Entwicklung von Software.<\/p>\n\n\n\n

Dass gerade die Verkn\u00fcpfung und gegenseitige Erg\u00e4nzung der verschiedenen Ma\u00dfnahmen wichtig ist, wurde im Gespr\u00e4ch mehrfach hervorgehoben und vor diesem Hintergrund er\u00f6rtert, wie sich die verschiedenen Formate konkret unterst\u00fctzen k\u00f6nnen. Beispielsweise k\u00f6nnte im Zuge der intensiven Auseinandersetzung mit einer Software im Reviewprozess des CKIT Journals das Anlegen eines Eintrags in die NFDI4Culture Registry (sofern noch nicht vorhanden) vorgeschlagen, empfohlen oder sogar obligatorisch gemacht werden. In der Registry wiederum k\u00f6nnten Reviews in CKIT verlinkt werden. Ein anderer Vorschlag zur Integration zielte darauf ab, Informationen zu einer bestimmten Software aus der Registry in einer Info-Box bei dem entsprechenden Review anzuzeigen. Eine solche wechselseitige Einbindung von Informationen k\u00f6nnte dabei helfen, veraltete Angaben als solche erkennbar werden zu lassen (was in verschiedenen Beitr\u00e4gen als eine zentrale Herausforderung bestimmt wurde).<\/p>\n\n\n\n

Eine Frage nach den Dom\u00e4nen vom CKIT Journal und der Software Registry verdeutlichte, dass der Gegenstandsbereich des Journals im Allgemeinen weiter gefasst ist als der der Registry, insofern darin auch Forschungssoftware, die in die Dom\u00e4ne anderer NFDI-Konsortien (die mitunter jeweils eine eigene Software Registry planen) f\u00e4llt, besprochen und rezensiert werden soll. Eine Koordination hinsichtlich der verschiedenen dom\u00e4nenspezifischen Registrys zwischen den NFDI-Konsortien ist bereits geplant und wird von der Arbeitsgruppe Research Software der NFDI Sektion Common Infrastructures diskutiert, in welcher Daniel Jettka und Daniel R\u00f6wenstrunk Mitglieder sind. Die Integration der Services und Angebote sollte zum einen innerhalb von NFDI4Culture erfolgen, zum anderen aber auch NFDI-weit. Dabei gilt es, das richtige Ma\u00df zwischen dem Abbilden bestimmter Eigenheiten einer Dom\u00e4ne und dem Vermeiden von Parallelentwicklungen zu finden.<\/p>\n\n\n\n

Nach diesen \u00dcberlegungen zur Position und zur Einbindung des CKIT Journals im Kontext von NFDI4Culture und der NFDI allgemein, wurde der Reviewprozess selbst diskutiert, der auch ein Peer-Review des Gutachtens vorsieht. F\u00fcr weitere Regulierungen des Prozesses will man sich an den Erfahrungen mit den ersten Reviews orientieren. Ausf\u00fchrlich wurde die Frage eruiert, wie mit m\u00f6glichen Befangenheiten bei der Beurteilung von Forschungssoftware umzugehen sei bzw. wie solche Befangenheiten zu bestimmen und zu bewerten sind. Denkbar ist z. B. eine Regelung, wer unter welchen Bedingungen Reviews f\u00fcr eine Software schreiben darf; damit soll verhindert werden, dass fehlende Distanz zum Projekt (und m\u00f6gliche Voreingenommenheit) zu weniger kritischen Reviews f\u00fchrt. Als problematisch wurde herausgestellt, bei einer relativ kleinen Community (und gro\u00dfer Vielfalt verwendeter Technologien und Methoden) Befangenheitskriterien festzulegen, ohne die Menge der Kandidat:innen so weit einzuschr\u00e4nken, dass Reviews hierdurch verhindert werden. Es wurde darauf hingewiesen, dass sich die Befangenheitsfrage auch bei der Beurteilung von Artikeln\/B\u00fcchern stellt, die Problematik sich aber insofern unterscheidet, als bei der (iterativen) Entwicklung von Software \u00fcber viele Jahre, Versionen und Komponenten hinweg, eine sehr gro\u00dfe Anzahl von Personen direkt beteiligt sein kann. Au\u00dferdem besteht das Dilemma, dass den besten Einblick in die Implementation einer Software diejenigen Personen haben, die in die Entwicklung involviert waren und dass der Aufwand technische Details nachzuvollziehen f\u00fcr jemanden, der in keiner Weise beteiligt gewesen ist, unverh\u00e4ltnism\u00e4\u00dfig gr\u00f6\u00dfer sein muss.<\/p>\n\n\n\n

Die Beurteilung von Forschungssoftware stellt auch insofern besondere Anforderungen, da sowohl fachlich als auch technologisch hochspezifische Kompetenzen erforderlich sind. Mit R\u00fccksicht auf diesen Sachverhalt ist bereits vorgesehen, dass im CKIT Journal \u201eTandem\u201c-Reviews erm\u00f6glicht werden sollen, bei denen sowohl Fachwissenschaftler:innen als auch Research Software Engineers zu einem Review beitragen. Durch den Hinweis, dass Rezensionen von Forschungssoftware noch nicht sehr verbreitet und au\u00dferdem noch nicht in das Anreizsystem der Wissenschaften integriert sind, ging die Diskussion dazu \u00fcber M\u00f6glichkeiten auszuloten, mit denen CKIT einen Beitrag zu einem allgemeineren Kulturwandel leisten kann. Wenn man auch nicht direkt Einfluss darauf nehmen kann, ob Betreuer:innen von Dissertationen Reviews als relevante Ver\u00f6ffentlichung werten, so stellt das Journal als Publikationsplattform doch den daf\u00fcr notwendigen Rahmen bereit. Daraus ergibt sich, dass man zum aktuellen Zeitpunkt die Anerkennung solcher Rezensionen als wissenschaftliche Publikation vor allem dadurch f\u00f6rdern kann, dass man f\u00fcr ein hohes Niveau sorgt; zum einen durch die Kriterien f\u00fcr Einreichungen, des Weiteren aber auch durch DOI-Vergabe, Peer-to-Peer-Verfahren und Zitation von Reviews.<\/p>\n\n\n\n

Bei der anschlie\u00dfenden Abstimmung wurden die vorgeschlagenen Kriterien f\u00fcr Einreichungen im CKIT Rezensionsjournal ohne Gegenstimmen best\u00e4tigt.<\/p>\n\n\n\n

Zertifizierung von Forschungssoftware<\/strong><\/h2>\n\n\n\n

Im weiteren Verlauf des Treffens ging es um M\u00f6glichkeiten der Zertifizierung von Forschungssoftware und deren Nachhaltigkeit, also konkret um die Frage, ob und in welcher Form NFDI4Culture wissenschaftliche Software evaluieren und zertifizieren sollte.<\/p>\n\n\n\n

Zun\u00e4chst stellten Aleksander Marcic und Daniel Jettka in einem kurzen Vortrag (Jettka\/Marcic, 2022<\/a>) verschiedene existierende Ans\u00e4tze f\u00fcr Softwarezertifikate und weitergehende \u00dcberlegungen zu Softwarezertifizierung vor. Die hierbei ber\u00fccksichtigten Aspekte umfassten u.a. Nutzer:innenperspektiven (Stakeholder), Kriterien zur Beurteilung, Verantwortlichkeiten f\u00fcr die Durchf\u00fchrung und Organisation von Zertifizierungsprozessen sowie weitere zeitliche und organisatorische Zusammenh\u00e4nge, wie die institutionelle Verankerung (Einzelpersonen, Projekte, Communities) einer Zertifizierung. Auch eine generelle Bewusstmachung, was Zertifikate \u00fcberhaupt sind und zu welchem Zweck sie eingesetzt werden, wurde forciert. In diesem Zusammenhang wurde auf eine generelle Definition f\u00fcr Zertifizierung nach ISO\/IEC 17000:2020<\/a> verwiesen:<\/p>\n\n\n\n

\n

\u201eMa\u00dfnahme durch einen unparteiischen Dritten, die aufzeigt, dass ein angemessenes Vertrauen besteht, dass ein ordnungsgem\u00e4\u00df bezeichnetes Erzeugnis, Verfahren oder eine ordnungsgem\u00e4\u00df bezeichnete Dienstleistung in \u00dcbereinstimmung mit einer bestimmten Norm oder einem bestimmten anderen normativen Dokument ist.\u201c <\/p>\n<\/blockquote>\n\n\n\n

Naheliegende Bez\u00fcge zu bereits in der Umsetzung befindlichen Ma\u00dfnahmen wie dem CKIT Journal, den NFDI4Culture Guidelines zu nachhaltiger Softwareentwicklung und der NFDI4Culture Registry fanden ebenfalls Beachtung, da es dort durchaus \u00dcberschneidungen hinsichtlich der verfolgten Ziele und zugrundeliegenden \u00dcberlegungen gibt. So beinhalten sie bspw. jeweils f\u00fcr sich bestimmte Grundannahmen, unter welchen Bedingungen Forschungssoftware als mehr oder weniger nachhaltig beurteilt werden kann.<\/p>\n\n\n\n

Durch die Verortung verschiedener Zertifizierungsans\u00e4tze und konkreter Zertifikate auf einer Skala zwischen den zwei Polen \u201eimplizite Beurteilung\u201c und \u201enormierte Zertifizierung\u201c wurde gezeigt, dass verschiedene M\u00f6glichkeiten der Explizierung von Beurteilung bzw. Zertifizierung denkbar sind und in der Praxis angewendet werden. So k\u00f6nnen Beurteilungen, die durch die Angabe obligatorischer Metadaten vorgenommen werden, bspw. als sehr implizit angesehen werden, w\u00e4hrend Zertifizierungen z. B. nach Vorgaben von DIN- oder ISO-Normen (etwa DIN, 2014<\/a> oder Normenreihe 250xx<\/a>) oder des Blauen Engels<\/a> als sehr explizit gewertet werden k\u00f6nnen. Als vielversprechender modularer Ansatz wurde das Konzept von Badges, deren Verwendung z. B. in GitHub und GitLab g\u00e4ngige Praxis ist, n\u00e4her betrachtet. Exemplarisch wurde das OpenSSF Best Practices Badge Program<\/a> aufgef\u00fchrt, das es Free\/Libre and Open Source Software (FLOSS) erm\u00f6glicht zu demonstrieren, dass sie Best Practices verfolgt und anwendet.<\/p>\n\n\n\n

Die anschlie\u00dfende Diskussion zielte darauf ab, zu einer gemeinsamen Einsch\u00e4tzung zu finden, wie Zertifizierungsprozesse und -mechanismen in NFDI4Culture ausgestaltet werden k\u00f6nnen und sollten. Hierbei wurde deutlich, dass umfassende Zertifizierungsprozesse (in Anlehnung an DIN und ISO) als zu aufwendig und nicht praktikabel angesehen werden. Die NFDI und viele der einzelnen Bausteine der Konsortien (wie die NFDI4Culture Registry und Guidelines, aber z. B. auch das CKIT Rezensionsjournal) befinden sich derzeit noch im Aufbau und es ist aktuell nicht absehbar, von welcher Institution ein eventueller Zertifizierungsprozess langfristig gepflegt und betreut werden k\u00f6nnte. Zudem bedeutet das Durchlaufen eines ausf\u00fchrlichen formalen Zertifizierungsprozesses selbst erheblichen Ressourcenaufwand, der unter den aktuellen F\u00f6rder- und Finanzierungsbedingungen f\u00fcr die Entwicklung von Forschungssoftware noch nicht gerechtfertigt werden kann.<\/p>\n\n\n\n

Vor diesem Hintergrund kam das Expert:innenforum zu der Empfehlung, aktuell keinen formalen Zertifizierungsprozess – im Sinne umfassender, normierter, Review-gest\u00fctzter Zertifizierung – f\u00fcr Forschungssoftware in NFDI4Culture umzusetzen. Stattdessen sollte der Fokus auf die Umsetzung der bereits geplanten und in der Umsetzung befindlichen Komponenten gelegt werden (z. B. Registry, Guidelines, Beratung). Diese erm\u00f6glichen und unterst\u00fctzen die Beurteilung von Forschungssoftware bereits auf unterschiedliche Weise.  Als Kandidat f\u00fcr ein geeignetes, flexibles Mittel zur \u00fcbergreifenden Darstellung von Beurteilungen einerseits und modular aufgebauten Umsetzung andererseits wurde das bereits erw\u00e4hnte Konzept von Badges festgehalten.<\/p>\n\n\n\n

Damit ergeben sich eine Reihe von Fragen, denen im Anschluss an das Treffen nachgegangen werden soll:<\/p>\n\n\n\n

    \n
  1. Welche existierenden Badges sind von Interesse und wie stehen sie zu den Informationsquellen und Nachhaltigkeitskriterien in NFDI4Culture?<\/li>\n\n\n\n
  2. Gibt es Kooperations- oder Beteiligungsperspektiven mit Blick auf bereits existierende Initiativen?<\/li>\n\n\n\n
  3. In welcher Form k\u00f6nnen und sollen existierende Badges einbezogen werden? Gibt es Entwicklungsbedarf f\u00fcr eigene Badges?<\/li>\n\n\n\n
  4. Wie k\u00f6nnen Badges \u00fcber Systeme\/Komponenten hinweg genutzt werden bzw. wie erfolgt die Verbindung von Systemen\/Komponenten mit Hilfe von Badges?<\/li>\n\n\n\n
  5. Welche Granularit\u00e4t sollten Badges abbilden – Low-level (Badges f\u00fcr einzelne Kriterien), High-level (Badge f\u00fcr Gesamtnachhaltigkeit) oder beides?<\/li>\n<\/ol>\n\n\n\n

    Referenzen<\/h2>\n\n\n\n

    <\/a>DIN (2014). ISO\/IEC 25000 System und Software-Engineering – Qualit\u00e4tskriterien und Bewertung von System- und Softwareprodukten (SQuaRE) – Leitfaden f\u00fcr SQuaRE. Online: https:\/\/www.din.de\/de\/mitwirken\/normenausschuesse\/nia\/veroeffentlichungen\/wdc-beuth:din21:204260933<\/u><\/a><\/p>\n

    <\/a>Jettka, Daniel & Marcic, Aleksander (2022). Beurteilung von Forschungssoftware in NFDI4Culture. Zenodo. https:\/\/doi.org\/10.5281\/zenodo.6536372<\/u><\/a>\u00a0<\/u><\/p>\n","protected":false},"excerpt":{"rendered":"

    verfasst von: Aleksander Marcic, Daniel Jettka (ORCID), Lisa Dieckmann (ORCID), Daniel R\u00f6wenstrunk (ORCID), Anne Ferger (ORCID) und Franziska Fritzsche (ORCID) Das NFDI4Culture Expert:innenforum zum Thema Nachhaltige Softwareentwicklung kam am 27. April 2022 zu seinem dritten virtuellen Treffen zusammen. Das Treffen wird in halbj\u00e4hrlichem Rhythmus organisiert vom Arbeitsbereich „Research Tools and Data Services“ des NFDI4Culture-Konsortiums. Die […]<\/p>\n","protected":false},"author":173,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,103,23,5,1165,4],"tags":[1272,88,802,1306,1693,837,428,741,518,742],"class_list":["post-17956","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-community","category-forschung-methode","category-forschungsinfrastruktur","category-publizieren","category-veranstaltungen","tag-forschungssoftware","tag-nachhaltigkeit","tag-nfdi","tag-nfdi4culture","tag-nfdi4culture-software-expertinnenforum","tag-research-software-engineering","tag-rezension","tag-software","tag-softwareentwicklung","tag-sustainability"],"_links":{"self":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/17956","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/users\/173"}],"replies":[{"embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=17956"}],"version-history":[{"count":5,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/17956\/revisions"}],"predecessor-version":[{"id":20570,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/17956\/revisions\/20570"}],"wp:attachment":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=17956"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=17956"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=17956"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}