{"id":19515,"date":"2023-07-18T16:27:26","date_gmt":"2023-07-18T14:27:26","guid":{"rendered":"https:\/\/dhd-blog.org\/?p=19515"},"modified":"2024-02-13T15:09:56","modified_gmt":"2024-02-13T14:09:56","slug":"5-expertinnenforum-nachhaltige-softwareentwicklung-in-nfdi4culture-institutionelle-professionalisierung-herausforderungen-und-perspektiven","status":"publish","type":"post","link":"https:\/\/dhd-blog.org\/?p=19515","title":{"rendered":"5. Expert:innenforum\u00a0\u201eNachhaltige Softwareentwicklung in NFDI4Culture\u201d: Institutionelle Professionalisierung \u2013 Herausforderungen und Perspektiven"},"content":{"rendered":"\n

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

Einf\u00fchrung<\/h2>\n

Im Fokus des f\u00fcnften Treffens des Expert:innenforums \u201eNachhaltige Softwareentwicklung in NFDI4Culture\u201d am 25. April 2023 standen institutionelle Aspekte der Professionalisierung von Softwareentwicklung in der Wissenschaft. Die Diskussuion wurde angeregt durch Impulse von Vertreter:innen von Rechen-, Daten- und DH-Kompetenzzentren, von F\u00f6rderern und aus der Lehre.<\/p>\n

Die Professionalisierung der Softwareentwicklung in der Wissenschaft steht vor der besonderen Herausforderung, dass Software gr\u00f6\u00dftenteils im Rahmen von Forschungsprojekten entwickelt wird, deren Finanzierung mit dem Projektende ausl\u00e4uft. Auch wenn diese Problematik nicht unmittelbar aufl\u00f6sbar ist, lassen sich Schl\u00fcsse und Lehren daraus ziehen, wie die verschiedenen institutionellen Akteure, z. B. Rechenzentren, Institute, DH-Kompezenzzentren, F\u00f6rderer und Infrastrukturprojekte mit dieser prek\u00e4ren Situation umgehen k\u00f6nnen.<\/p>\n

Die Rolle von Zentren (Rechenzentren, Daten- und DH-Kompetenzzentren)<\/h2>\n

Da Softwareentwicklung in der Wissenschaft gr\u00f6\u00dftenteils in Projektkontexten stattfindet und f\u00fcr Mitarbeiter:innen nicht immer eine Anschlussfinanzierung m\u00f6glich ist, geht in Projektlaufzeiten aufgebaute Expertise immer wieder verloren. Die\u00a0Sicherstellung von ad\u00e4quatem Wissenstransfer\u00a0durch stabilisierende Elemente\u00a0ist daher eine zentrale Herausforderung. Aus diesem Grund werden Institutionen ben\u00f6tigt, die f\u00fcr die Softwareentwicklung \u00fcber Projektlaufzeiten hinaus Wissen transferieren und Infrastruktur kontinuieren. In der Praxis bedeutet dies:<\/p>\n

    \n
  • Verschiedene Institutionen (z. B. Rechenzentren, Bibliotheken, Daten- und DH-Kompetenzzentren, Institute\u00a0aus Fachdisziplinen) sollten zielgerichtet zusammenarbeiten.<\/li>\n
  • Wenn diese Aufgabe auf verschiedene kleinere Institutionen verteilt ist, k\u00f6nnen Vorteile genutzt werden, etwa eine h\u00f6here Flexibilit\u00e4t und Spezialisierung. Gleichzeitig besteht die Gefahr der Zersplitterung von Wissen durch verteilte Strukturen.<\/li>\n
  • F\u00fcr sehr kleine Teams kann es schwer sein, gleichzeitig alte Infrastruktur in Stand zu halten (z. B. um alte Projekte weiter zu betreiben) und neue Technologien zu evaluieren und damit zu experimentieren.<\/li>\n<\/ul>\n

    \u00a0<\/p>\n

    Ohne feste Mittel f\u00fcr langfristige Entwickler:innenstellen besteht eine weitere besondere Herausforderung in der\u00a0Aus- und Weiterbildung von RSEs an DH-Kompetenz- und Rechenzentren\u00a0mit dem Ziel eines langfristigen Aufbaus von dom\u00e4nenspezifischer und technischer Expertise. Aus diesem Grund sind im Rahmen des Forums verschiedene Beispiele aus der Praxis vorgestellt worden, wie mit dieser Herausforderung umgegangen werden kann:<\/p>\n

      \n
    • An Zentren kann RSEs erm\u00f6glicht werden, sich weiterzubilden und erworbene Kenntnisse ins Team zur\u00fcckzuspielen.<\/li>\n
    • F\u00fcr Systemadministration und -integration k\u00f6nnen Ausbildungstellen angeboten und Auszubildende in Projektarbeit einbezogen werden.<\/li>\n<\/ul>\n

      \u00a0<\/p>\n

      Auch wenn sehr h\u00e4ufig noch keine direkte Finanzierung fester Entwickler:innenstellen von \u00fcbergeordneten Institutionen zur Verf\u00fcgung gestellt wird, k\u00f6nnen u.U. verschiedene Mittel geb\u00fcndelt oder (im besten Fall l\u00e4ngerfristige) Kooperationen eingegangen werden. Konkret genannt wurden:<\/p>\n

        \n
      • (Aushandlung der konkreten Verwendung von) Overhead-Mitteln, d .h. flexiblen Mitteln, die bei Projektf\u00f6rderung von Mittelgeber:innen zur Verf\u00fcgung gestellt werden<\/li>\n
      • Pooling von Mittelanteilen aus verschiedenen Projekten f\u00fcr zentrale Stellen (nur mit vielen Projekten machbar)<\/li>\n
      • Langzeitkooperationen (z. B. mit Akademien) erm\u00f6glichen wenigstens mit einem kleinen Teil der Mittel l\u00e4ngerfristig planen zu k\u00f6nnen<\/li>\n<\/ul>\n

        \u00a0<\/p>\n

        Die Rolle von Software in Forschung und wissenschaftlicher Ausbildung<\/h2>\n

        Eine weitere Herausforderung f\u00fcr die Professionalisierung der wissenschaftlichen Softwareentwicklung ist, dass Software in den meisten Wissenschaften zwar ein fester Bestandteil der Forschung, zugleich in vielen F\u00e4chern aber kein fester Bestandteil der wissenschaftlichen Ausbildung ist.<\/p>\n

        Vorbehalte\u00a0gegen\u00fcber Softwareentwicklung\u00a0als genuinem Bestandteil eines Faches, scheint in vielen F\u00e4chern der Geisteswissenschaften vorhanden zu sein. Das hat Konsequenzen f\u00fcr Ausbildungsangebote im Rahmen der jeweiligen Studieng\u00e4nge sowie f\u00fcr die Anerkennung von Softwareentwicklung als wissenschaftlichem Beitrag. Problematisch ist hierbei z. B. insbesondere:<\/p>\n

          \n
        • Studierende k\u00f6nnen ihre erworbenen Kompetenzen nicht ohne Weiteres als Studienleistung anerkennen lassen, was dazu f\u00fchren kann, dass Angebote trotz bestehendem Interesse seltener wahrgenommen werden.<\/li>\n
        • Es herrscht Ungewissheit, ob Kompetenzen und Code-Beitr\u00e4ge f\u00fcr die weitere wissenschaftliche Qualifikation in den F\u00e4chern angerechnet werden.<\/li>\n<\/ul>\n

          \u00a0<\/p>\n

          Der Gruppe gut vernetzter Wissenschaftler:innen im Bereich der Digital Humanities und RSEs stehen zahlreiche Fachwissenschaftler:innen gegen\u00fcber, die zwar digitale Methoden und Werkzeuge anwenden, Scripts schreiben usw., aber am Austausch (und z. B. auch an Standardisierungsprozessen) der Community nicht direkt beteiligt sind. Hieraus ergibt sich:<\/p>\n

            \n
          • Probleme der Nachhaltigkeit von Softwarel\u00f6sungen, etc. werden h\u00e4ufig v. a. im Kreis sachkundiger Expert:innen diskutiert, so dass die Problemhorizonte jeneits dieser Kreise (z.B. in den einzelnen F\u00e4chern) weitgehend unbekannt sind und gegebenenfalls erst vermittelt werden m\u00fcssen.<\/li>\n
          • Interessierte, aber nicht bereits technisch sachkundige Wissenschaftler:innen k\u00f6nnen durch diese Diskrepanz von anspruchsvollen L\u00f6sungsans\u00e4tzen abgeschreckt und \u00fcberfordert werden.<\/li>\n
          • Ob einzelne L\u00f6sungsans\u00e4tze auch im Arbeitsalltag der Fachwissenschaftler:innen plausibel sind und akzeptiert werden, muss zus\u00e4tzlich ermittelt [bzw. ber\u00fccksichtigt] werden.<\/li>\n
          • Zudem ergibt sich weiterhin die Frage, wie weiter und besser mit dieser Kluft umzugehen ist.<\/li>\n<\/ul>\n

            \u00a0<\/p>\n

            Nicht selten fallen Defizite bei der Planung und Umsetzung digitaler Komponenten in Forschungsprojekten erst auf, wenn zum Ende und mit Blick auf die Nachhaltung von Ergebnissen\u00a0Kontakt z. B. mit Datenzentren aufgenommen wird. Datenzentren (u. a.) haben derzeit in der Regel nicht die Kapazit\u00e4ten eine enge Begleitung in der Softwareentwicklung zu leisten oder im Nachhinein nicht nachhaltig entwickelte Software in nachhaltige zu verwandeln. In diesem Zusammenhang ist zu beachten:<\/p>\n

              \n
            • Es ist manchmal nicht vermeidbar Software im Nachhinein anzupassen, bspw. wegen Vers\u00e4umnissen am Projektanfang \u2013 etwa (a) Umgang mit personenbezogenen Daten, (b) rechtlichen Beschr\u00e4nkungen externer Partner.<\/li>\n
            • Die Erwartung einer Standardisierung von technischen Stacks ist zwar nachvollziehbar, wird jedoch als wenig aussichtsreich erachtet.<\/li>\n
            • In Beratungsangeboten und Leitf\u00e4den, etc. k\u00f6nnen Best Practices und Standards f\u00fcr die Softwareentwicklung kommuniziert und diskutiert werden<\/li>\n
            • Register (wie die NFDI4Culture Software Registry u. \u00e4.) etc. k\u00f6nnen indirekt zu einer gewissen Vereinheitlichung beitragen<\/li>\n<\/ul>\n

              \u00a0<\/p>\n

              In Bezug auf bestehende F\u00f6rderstrukturen und -angebote ist festzustellen, dass viele der Probleme im Kontext der wissenschaftlichen Softwareentwicklung den Projektf\u00f6rderern zwar bekannt sind, eine notwendige Anpassung der F\u00f6rderung aktuell dennoch vor einer Reihe von zentralen Herausforderungen steht:<\/p>\n

                \n
              • Es braucht eine Definition von Forschungssoftware, die vom Code Block im Jupyter Notebook bis zur ger\u00e4tespezifischen medizinischen Software alles umfasst.<\/li>\n
              • Eine Erh\u00f6hung der F\u00f6rdergelder kann den ungewollten Effekt nach sich ziehen, dass die Kosten f\u00fcr Entwicklung steigen.<\/li>\n
              • Es m\u00fcssen F\u00f6rderprogramme entwickelt werden, in denen die Bedarfe der Geisteswissenschaften ebensosehr Entsprechung finden, wie die in Natur- und Ingenieurswissenschaften, Medizin, etc.<\/li>\n
              • Eine \u00dcbersicht \u00fcber vorhandene Software ist n\u00f6tig, um F\u00f6rderbedarfe besser beurteilen zu k\u00f6nnen (in diesem und anderen Zusammenh\u00e4ngen ist die Bedeutung von Softwarekatalogen und -registern f\u00fcr F\u00f6rderung und Studiengangsaufbau mehrfach hervorgehoben worden).<\/li>\n<\/ul>\n

                \u00a0<\/p>\n

                Die Rolle von Software in der Forschung ist vielf\u00e4ltig und f\u00fcr die F\u00f6rderung, die Anspr\u00fcche an Nachhaltigkeit (z. B. hinsichtlich Entwicklungsprozess, Dokumentation usw.) stellt, ist es hilfreich, verschiedene Rollen zu unterscheiden. Generell kann Software einerseits als Mittel zur Beantwortung von Forschungsfragen eingesetzt werden, andererseits aber auch selber Gegenstand von Forschung sein. Und w\u00e4hrend Software h\u00e4ufig im Hinblick auf ganz spezifische Forschungsfragen (im Rahmen von Forschungsprojekten) entwickelt wird, muss auch die Entwicklung allgemeinerer Software bei Finanzierung, F\u00f6rderung, Nachhaltigkeits\u00fcberlegungen etc.\u00a0 ber\u00fccksichtigt werden.<\/p>\n

                  \n
                • F\u00fcr experimentelle Software muss der Betrieb meist nicht Jahre \u00fcber Projektende hinaus gesichert werden<\/li>\n
                • F\u00fcr sehr spezielle Software m\u00fcssen Nachhaltigkeitsstrategien, Dokumentation etc. auf Nachvollziehbarkeit, f\u00fcr Software mit erkanntem Verallgemeinerungspotenzial auf Nachnutzbarkeit und Weiterentwicklung ausgerichtet sein.<\/li>\n
                • Aufbau und Management von Communities sind inh\u00e4rente Aufgaben bei der Entwicklung von (allgemeinerer) Software.<\/li>\n
                • F\u00f6rderprogramme zur Verallgemeinerung projektspezifischer Software werden bereits entwickelt und getestet, sind aber noch nicht fest etablierter Bestandteil der F\u00f6rderlandschaft.<\/li>\n
                • Bedarfe sowohl der Fach- als auch der Entwickler:innen-Communities m\u00fcssen sichtbar gemacht werden.<\/li>\n<\/ul>\n

                  \u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

                  verfasst von: Aleksander Marcic (ORCID), Daniel Jettka (ORCID), Lisa Dieckmann (ORCID), Daniel R\u00f6wenstrunk (ORCID), Anne Ferger (ORCID), Franziska Fritzsche (ORCID) Einf\u00fchrung Im Fokus des f\u00fcnften Treffens des Expert:innenforums \u201eNachhaltige Softwareentwicklung in NFDI4Culture\u201d am 25. April 2023 standen institutionelle Aspekte der Professionalisierung von Softwareentwicklung in der Wissenschaft. Die Diskussuion wurde angeregt durch Impulse von Vertreter:innen von […]<\/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,6,5,242,4],"tags":[1693],"class_list":["post-19515","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-community","category-forschungsfoerderung","category-forschungsinfrastruktur","category-lehre-und-ausbildung","category-veranstaltungen","tag-nfdi4culture-software-expertinnenforum"],"_links":{"self":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/19515","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=19515"}],"version-history":[{"count":4,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/19515\/revisions"}],"predecessor-version":[{"id":19795,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/19515\/revisions\/19795"}],"wp:attachment":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19515"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19515"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19515"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}