Empfehlungen für bessere Forschungssoftware
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 60 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/42521 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
6
13
21
25
41
53
00:00
Software engineeringSoftwareComputer programmingChecklistVersion <Informatik>World Wide WebAdditionComputer programmingSoftwareContent (media)Run-time systemSoftware engineeringPlane (geometry)Film editingKennzahlSocial classProduct (category theory)Query languageFile formatChecklistProgramming languageSoftware-EntwicklungsprojektInterface (computing)Software developerFeedbackSoftware repositoryLecture/ConferenceComputer animation
06:58
State transition systemVersion <Informatik>AdditionComputer programmingNeWSChecklistINGA <Programm>FrictionOpen source9 (number)Data conversionStructural loadUpdateCodeSpatial data infrastructureSample (statistics)Revision controlSocial classMobile appSoftwareProgramming languageStandard deviationWage labourSoftware developerAverageFunction (mathematics)Software testingControl flowSample (statistics)Scripting languageModule (mathematics)AutomationAtomic nucleusScripting languageInformationCodeOpen sourceSoftware repositoryGit <Software>Computer animation
13:40
makeSoftwareData conversionSpatial data infrastructureService (economics)Manufacturing execution systemVersion <Informatik>Open sourceCodeRun-time systemWalkthroughSoftware engineeringComputer programmingDirection (geometry)Social classMach's principleSoftwareInformationChecklistTemplate (C++)MittelungsverfahrenApple KeynoteComputer fileRun-time systemData managementSoftware developerVersion <Informatik>Git <Software>Open sourceSoftware testingFocus (optics)Data conversionControl flowCodeWeightComputer animation
20:21
TOUR <Programm>Software engineeringRun-time systemWalkthroughCodeEULER <Compiler>TwitterRun-time systemPDF <Dateiformat>ChecklistSoftwareWeb pageGrand Unified TheoryVersion <Informatik>Computer animation
21:22
SoftwareChecklistDirection (geometry)AutomationPAPInformationRun-time systemWikiNumberWeb pageDigital object identifierMittelungsverfahrenVersion <Informatik>RoundingScripting languagePlane (geometry)Software developerWordWebsiteEckeTransmitterWindowLecture/ConferenceMeeting/Interview
Transcript: German(auto-generated)
00:02
Herzlich willkommen zu meinem Talk, Empfehlung für bessere Forschungssoftware. Tobias Schlauch arbeitet beim DLR und wir machen ein bisschen Softwareentwicklung. Wir haben derzeit ungefähr 8.000 Mitarbeiter, das ist schon mal so eine Sache. Davon mache ich auch, das ist so eine geschätzte Zahl, knapp 20% auch Softwareentwicklung.
00:25
Wir haben morgen auch nochmal einen Talk, wo wir ein bisschen mehr in die Details reingehen. Wir haben auch jetzt im letzten Jahr nochmal eine Umfrage gemacht. Da haben wir auch schon mal von 600 Softwareentwickelnden auch nochmal Rückmeldungen bekommen. So was die Top-Programmiersprache ist im DLR, wer das wissen möchte. Das gibt es dann morgen.
00:41
Spoiler-Python. Lohnt sich aber trotzdem auch nochmal der Vortrag morgen. Eine andere Herausforderung sieht man schon hier, das sind unsere Standorte. Wir sind schon extremst verteilt. Und auch inhaltlich, man denkt jetzt Luft- und Raumfahrt ist nur Luft- und Raumfahrt. Wir haben aber noch Verkehr, Energie, Sicherheit.
01:02
Das sind so Programmatiken. Und da sind dann auch noch die Institute, verschiedene Institute darunter angesiedelt. Und die Institute sind halt schon so gewisse Institutionen auch für sich. Die lassen sich da auch nicht in alle Sachen reingucken, was man typischerweise hat. Deswegen ist es auch jetzt nicht verwunderlich, dass wir da auch eine relativ große Breite haben.
01:25
Also eine Forschungssoftware, die je nach Domäne gebaut wird. Wir haben auch, wie reif oder wie groß oder umfangreich so eine Software ist, das ist halt eben auch sehr unterschiedlich. Das sind typische Datenauswertungsskripte, die haben wir natürlich eben auch. Bis dann halt irgendwelche Simulationsframeworks für aerodynamische Phänomene,
01:45
die dann am einen Institut hauptsächlich entwickelt werden, die dann in Kooperation mit Airbus quasi Forschungsprodukte letztendlich sind. Aber dafür ist keiner zentral im DLR verantwortlich, sondern das jeweilige Institut. Und da sieht man schon, dass das eigentlich eine interessante Komplexität ist.
02:01
Programmiertechnologien haben auch ziemlich alles drin. Und die Teamgrößen, ja, wir haben natürlich viele auch so Einzelentwicklerinnen und Entwickler, aber meistens so sind das so, im Schnitt sind das vier, fünf, sechs Leute oder so, wenn es denn bei größeren Sachen hochkommt. Genau, so viel dazu. Ich arbeite bei der Einrichtung Simulations- und Softwaretechnik
02:22
und wir haben halt auch schon historisch eigentlich relativ viel im Bereich Softwareentwicklung halt auch gemacht. Und dann kam auch mal die Idee, naja, können wir das nicht auch versuchen, was so grundlegend so Entwicklungspraktiken sind, das ein bisschen im DLR anzuschieben. Und ich arbeite bei uns in der Gruppe Softwareengineering, die Carina,
02:42
die hier auch die Konferenz mit organisiert hat. Das ist meine Gruppenleiterin. Und wir sind eigentlich sowas wie so ein zentrales RSE-Team fürs DLR. Also wir koordinieren verschiedene übergreifende Sachen und versuchen das auf der Ebene anzuschieben. Das reicht natürlich nicht, wir müssen natürlich auch die anderen mit ins Boot kriegen.
03:04
Und wir haben das dann mal so Softwareengineering-Initiative vor ein, zwei Jahren mal zusammengenannt. Und das steht so auf verschiedenen Säulen, die sich auch so gegenseitig dann eben ergänzen. So ein Punkt, den man nicht unterschätzen sollte, ist halt sowas wie Policyentwicklung. Weil ja, Publikation ist dann oft doch wichtiger oder das Feature und so weiter,
03:23
anstatt vielleicht so ein paar Sachen ein bisschen sauberer zu machen. Auch wenn die Leute das denn wollen, dann kommt der Chef und sagt, naja, macht das mal lieber fertig und so. Deswegen ist auch wichtig, dass das okay ist und dass es da irgendwie so eine Policy auch intern gibt, dass das auch ein wichtiger Punkt ist. Teil von dieser Policy darüber sind auch diese Softwareengineering-Empfehlungen.
03:43
Davon werde ich jetzt nochmal ein bisschen was erzählen, wofür wir die eigentlich benutzen. Und dann natürlich dazu ergänzend die Werkzeuge. Das ist immer nett, wenn man sagt, okay, macht man das und das. Aber wenn man dann sagt, okay, jetzt musst du dir noch dein Versionskontrollsystem selber hosten oder so, dann ist die Wahrscheinlichkeit bei allen anderen Sachen, die man machen muss, natürlich wesentlich geringer, dass das dann auch gemacht wird.
04:03
Ergänzend dazu machen wir auch Trainings intern. Die sind dann halt eben genau ausgerichtet auf die Empfehlungen. Also welche Entwicklungspraxis wollen wir dann eben im DLR verbreiten und auf diese Werkzeugumgebung. Also wir machen nichts, was man nicht auch irgendwie natürlich einkaufen könnte,
04:20
sondern eben genau auf diese Schnittstelle bedacht sozusagen. Genau, Consulting machen wir auch intern. Also Leute unterstützen, ihre Software-Entwicklungsprojekte ein bisschen besser zu koordinieren. Das sind solche Sachen. Und natürlich dieser ganze Community-Aufbau- und Erfahrungsaustausch. Also jetzt schon mal gespoilert, diese Empfehlungen sind halt nur ein kleiner Teil sozusagen.
04:41
Und diese ganze Umgebung drum herum, das ist eigentlich nachher das Entscheidende, wenn man so eine Thematik so kulturell besser in auch so einer großen Forschungsinstitution etablieren möchte. Die Empfehlungen sind erstmal nur sowas hier wie hier dargestellt. Wir haben im Prinzip gemeinsam in so einer Art Reference Guide für die Entwicklungspraxis,
05:07
die wir im DLR haben wollen, halt eben entwickelt. Und damit man die auch mal für seine Software auch anwenden kann, haben wir halt so Checklisten rausgebracht, die auch in unterschiedlichen Formaten dann zur Verfügung stehen, damit man das halt zum Beispiel auch ins Repository packen kann.
05:22
Also nicht so wie hier diese Word, sondern eben auch in Markdown, in Restructured Text. Das wird dann alles von diesen Inhalten im Prinzip abgeleitet. Und die Idee ist halt eben schon, dass ich einem Software-Entwickelnden was in die Hand geben kann und erstmal eine Standortbestimmung machen kann. Na ja, wo stehen wir denn ungefähr mit unserer Software? Und dann ist insbesondere das Interessante, na ja, was sind denn die zwei, drei Sachen, die wir besser machen können?
05:44
Also das kontinuele ich hier, dieses Thema verbessern. Die sind insgesamt über einen Daumen 78 Empfehlungen. Die haben wir thematisch sortiert. Das sind so Themen drinne wie Anforderungsmanagement, Änderungsmanagement, Softwarearchitektur, Software-Testing.
06:01
Wie sollte ich bei der Veröffentlichung vorgehen beim Release von der Software? Was sind so Sachen, wo ich automatisieren kann? Und wir haben die dann auch nochmal, sage ich mal, versucht, so gewisse Anwendungsklassen, Anwendungstypen letztendlich zu finden, um auch auf dieser Ebene halt nochmal einen anderen Einstieg einzugehen. Ich glaube, dass ich hier vielleicht bloß sechs, sieben Empfehlungen am Start bei der Anwendungsklasse eins beispielsweise habe.
06:28
Das System, das wir uns überlegt haben, sollte bewusst einfach sein, weil sobald man da noch 30 Vorabfragen macht, dann spielen die Leute damit schon alleine mit den Vorabfragen und gucken, wo sie am wenigsten rauskommen.
06:41
Das haben wir relativ klar kommuniziert. So eine Anwendungsklasse, die Empfehlungen, die dazugehören, das ist so ein Startpunkt. Das heißt nicht, dass das absolut, dass das hundertprozentig passt, das ist auch nicht die Intention, sondern das kann für den Zweck ganz sinnvoll sein und guckt mal, was er noch dazunehmt, oder welche Sachen lasst er auch raus. Und es hat auch nicht den Anspruch, dass man das jetzt sofort für alles macht,
07:03
sondern dass es halt zur Unterstützung drüber nachdeckt, hey, wie kann ich meine Software in welchen Bereichen beispielsweise fertig machen. Zum Beispiel eine von diesen Grundanforderungen ist zum Beispiel, jetzt auch wenig Überraschung, dass man wenigstens seine Software unter Versionskontrolle stellt, also sowas wie Git oder GitLab beispielsweise einsetzt.
07:22
Dann haben wir diese Anwendungsklasse 1, das ist eher so für Datenauswerte, Skripte beispielsweise. Die ist halt klein, aber der entscheidende Punkt hier ist schon, dass das andere nutzen. Also da muss man schon ein bisschen immer was tun. Sobald man ein bisschen Doku dazutun, da sollte es vielleicht einfach sein, das Ganze zu nutzen. Das sind solche Grundanforderungen. Die anderen Anwendungsklassen, die bauen im Prinzip darauf auf und erweitern das Ganze.
07:41
Zum Beispiel die Anwendungsklasse 2, das ist schon so ein Simulationsframework, ein Beispiel dafür ist ein Simulationsframework, was ich auch wirklich längerfristig im Institut habe und was ich auch weiterentwickle, weil ab einer gewissen Größe sozusagen von so einer Software und insbesondere,
08:01
wenn ich die über einen längeren Zeitraum behalten möchte und erhalten möchte, dann muss ich halt schon mit ein paar anderen Maßnahmen daran gehen. Da reicht es mir nicht nur irgendwie was unter Versionskontrolle zu stellen, sondern da muss ich irgendwie mal über Automatisierung nachdenken, über automatisierte Tests, Unit Testing, da muss ich vielleicht auch ein bisschen mehr aufschreiben, über die Softwarearchitektur, damit sich da auch wieder einer rein findet,
08:22
weil wir haben ja schon im Forschungskontext immer eine gewisse Fluktuation. Wie kriegen wir die Leute da möglichst rein? Und ehrlicherweise haben wir uns bei der Erarbeitung, bei diesen Empfehlungen auch so drauf geachtet, was ist denn das, was uns immer gefehlt hat, wenn wir eine andere Software übernehmen mussten? Das war so platt die Idee dabei, weil da merkt man es am meisten. Wir haben noch so eine Anwendungsklasse 3, dass wirklich für diese produktartigen Sachen,
08:43
die irgendwie kritisch für den Erfolg sind, da kommen noch ein bisschen mehr Vier-Augen-Prinzips-Sachen dazu. Und weil das Teil unserer Policy ist, haben wir das A-Empfehlungen genannt, damit ihnen die Leute nicht gleich mit Regeln abgeschreckt werden. Und das Zweite ist, es gibt so eine Anwendungsklasse 0 sozusagen, da gehen wir nichts vor, das sind die Sachen, die ich für mich selber baue, die müssen, die ich nur für mich baue, das ist ja immer so.
09:06
Aber im Kern ist das eigentlich hier auch für die Institute, dass die sich selber das denn überlegen können, sozusagen, um das so ein bisschen offen zu halten. Das ist so die Idee. Und typischerweise, wenn ich damit arbeite, würde ich halt mal gucken, wo lande ich dann am Anfang mit diesen Fragen, unterstützt bei welcher Anwendungsklasse,
09:21
lande ich dann ungefähr und dann gucke ich mir das an und checke erstmal meine Software halt eben dagegen. Und das kann sich so eine Zuordnung auch ändern. Das ist ja eigentlich auch typisch oder in der Forschung, dass sich so Sachen entwickeln, aber es muss nicht. Also ein Datenauswerteskript bleibt ein Datenauswerteskript. Das ist hier nicht, wir wollen nicht plus plus weiter hochgehen.
09:40
Kann sich ändern, aber es gibt, wenn ich eine Auswertung mitgemacht habe und das dann abgeschlossen veröffentlicht habe, dann war es das damit. Da muss ich nicht mehr machen. Ein bisschen nochmal anfassbarer zu machen, das waren ungefähr so die allgemeinen oder generischen Empfehlungen von dieser Anwendungsklasse 1 mal zusammengefasst. Also klar, Version-Control-Basis für alle Sachen, die wir darauf aufbauen wollen.
10:04
Dann, ich habe es mal zusammengefasst, Einhaltung und grundlegende Entwicklungspraktiken. Das sind so Sachen, naja, nutze mal die Modularisationsmechanismen deiner Programmiersprache. Also gerade, wenn die Leute noch nicht so tief drin sind, kenne dein Tool, mach mal Module, mach mal Funktionen, nutze den Standard-Code-Style in Python zum Beispiel, die PP8.
10:23
Gibt es auch ein Tool Black, da muss ich mich gar nicht mehr drum kümmern. Der Frau markiert meinen Code schon. Das sind so Sachen, damit er wenigstens halbwegs vernünftig aussieht sozusagen. Dann, das heißt auch so schön allgemein, Bereitstellung essenzieller Dokumentation. Das heißt, aber der Punkt ist, das hängt ja auch immer so ab vom Kontext.
10:41
Das wollte ich vielleicht hier auch nochmal erwähnen. Deswegen, auch hier auf dem Kontext kommt es an, wie ich die dann eben ausarbeite. Zum Beispiel, wenn ich das nur bereitstelle und irgendwie eigentlich nur Nutzer, also einen habe, der mal die, vielleicht die Analyse nochmal nachbauen möchte, dann muss ich natürlich hauptsächlich Nutzungsinformation, was muss ich installieren, in welchen Schritt, damit ich das ausprobieren kann. Wenn ich Leute haben möchte, die mitentwickeln,
11:01
dann muss ich mir schon ein bisschen Contribution Guidelines überlegen. Dann mache ich das über Pull-Request, Issues und so weiter. Dann muss ich das aber auch aufschreiben, sonst kommt keiner. Also Leute, wenn ihr Contributor haben wollt, die wollen es halt einfach haben, wie läuft das und wenn du das nicht sehen, dann ist das schon die erste große Hürde. Dann muss ich das eben auch aufschreiben. Auch die Erstellung von so einer Version, dass ich die wenigstens nutzen kann
11:23
oder dass ich sie bei mir laufen lassen kann, wenn ich mitentwickeln möchte, dann kann ich das auch möglichst einfach beschreiben und möglichst soweit automatisieren, wie es halt eben geht. Selbst schon in diesem Bereich. Aber was das genau heißt, ist immer von ab. Wenn ich die nur, sage ich mal, im DLR bei uns veröffentliche, sollte ich trotzdem, also wenn ich diesen Stand halt weitergebe, dann sollte ich den auch mal testen, dass er das tut, was er macht.
11:42
Und dann sollte ich ihn auch irgendwie kennzeichnen. Versions-Control-Tech beispielsweise. Und ich kann auch sowas wie Release-Nummer nutzen. Das tut nicht weh. Das ist nicht fair. Es tut nicht weh. Kann man danach viel besser sehen, was da irgendwie dranhängt. Aber wenn wir natürlich einen Open Source Public Release machen,
12:00
dann haben wir nochmal ein paar zusätzliche Infos gerade über Lizenzen und so weiter, wo man das mal durchgucken sollte. Aber hier die Message, wenigstens eine Lizenz dazutun, okay? Ganz wichtig. Sonst kann das leider keiner was damit anfangen. Hier nochmal ein Beispiel. Das ist ein kleines Python-Skript, was im Prinzip aus einer Stichprobe irgendwie Mittelwert und Standardabweichung berechnet.
12:24
Tut nicht viel. Aber so ein paar Sachen drumherum habe ich mit dazu ins Repository getan. Wichtig ist erstmal, das ist halt ein Git-Repository. Das ist jetzt ein GitLab-Projekt bei uns. Da ist natürlich der Code drinne, aber natürlich noch mehr. Also alles, was eigentlich zur Software gehört, gehört da eben auch mit rein. Die Doku.
12:40
Da sind ein paar Beispiele drinne. Wie rufe ich das Ganze auf? Wie kommt das rein? Wie geht das raus? Das ist ein kleines Bildskript und natürlich sowas wie Dokumentation. Ein paar Sachen habe ich hier schon gesagt. Der Code, müsste man jetzt glauben, der ist jetzt irgendwie in Funktionen zerteilt. Wir haben da die pp8 angewendet. Wir haben noch ein paar Beispiele mit reingetan. Gibt ein kleines SetupPy, um das Ganze zu pakettieren.
13:04
So ein ZIP-Archiv zum Beispiel draus zu bauen, das weiterzugeben und es dann eben zu installieren. Wir haben eine kleine Changes-MD dazu getan, wo dann so die wichtigsten Änderungen letztendlich drin sind. Das sind auch Teil von der Dokumentation, wenn man das auch so ein bisschen sich weiterentwickelt, die sich dann halt eben lohnt.
13:21
Wenn ich das halt nur einmal mache, dann ist das vielleicht ein bisschen over the top, aber da muss man immer gucken, was mache ich damit eigentlich mit der Software. Auch mal zur Dokumentation, um diese essentielle Dokumentation ein bisschen klarer zu machen, ist halt üblicherweise heute eine ReadMe.
13:40
Wenn ihr irgendwas auf GitLab oder GitHub packt, immer eine schöne ReadMe dazutun. Das ist so die erste Werbe-Seite, die jeder sieht und die sollte schön klar sein. Erstmal, was ist es? Also wie heißt das Ding? Was tut es? Was hat es für Hauptfunktionen letztendlich? Wozu ist es gut? Also was macht es? Für wen ist es da? Und warum hat sich das einer schon zum dritten Mal nochmal ausgedacht?
14:02
Kann man auch erst mal vorher schon überlegen und es gibt oft einen guten Grund, weil immer wenn so was aussieht wie Datenmanagement zum Beispiel, Verwaltungswerkzeug, heißt es nicht, dass die irgendwie immer gleich sind. Die haben halt andere Grundgerüst, wofür sie halt eben da sind. Auch so Nutzungseinschränkungen sind immer ganz spannend zu finden. Und wie installiere ich das jetzt hier?
14:21
Das ist jetzt hauptsächlich für Nutzer eben aufgebaut. Genau, da gibt es auch eine Contributing-MD. Das ist auch so eine typische Datei auch im Open Source Umfeld, die man halt eben anlegt, wo man dann reinschreibt. Na ja, wenn ich was beitragen möchte, weil das ein tolles Software ist, wie kriege ich dann meinen Codebeitrag bei dir denn eigentlich letztendlich unter? Das ist so hier der Punkt.
14:44
Für die Details gibt es da sehr schöne Templates auch. Wenn man auf GitHub mal ein bisschen sucht, da gibt es ein paar ganz schöne Sachen, wie man sowas aufsetzen kann. Das ist aber so eine minimale Geschichte. Das war jetzt erstmal so ein bisschen um die Basics von dieser Anwendung Klasse 1 nochmal zu zeigen.
15:01
Gehen wir mal ganz kurz zurück. Genau, Version Control, Entwicklungspraktiken PP8 und sowas hatte ich mal kurz gezeigt. Wie kann man so eine Doku denn ausprägen sozusagen? Wie kriege ich so eine Version halt eben hin über so eine Setup Pie und so weiter und dann halt eben auch das mit dem Release-Nummer. Gut, eine interne Geschichte, deswegen war auch kein Lizenz jetzt gerade dabei.
15:22
Genau, so, ansonsten. Wir haben hier tatsächlich diesen Empfehlungskatalog. Den haben wir jetzt schon, naja, seit 2016, 2017 sozusagen um die hier ausgerollt. Den zu verteilen und die Leute zu bringen, ist schon eine gewisse Geschichte. Das funktioniert auch nicht, wenn ich mich da hinstelle und das irgendwo rumschicke per Mail sozusagen.
15:42
Deswegen, das hängt auch ein bisschen von der Umgebung jetzt endlich ab. Aber dazu sage ich gleich noch was. Ein bisschen was hat man da am Anfang schon mal gesehen. Aber durchaus, was wir so an Feedback bekommen, das hilft den Leuten, sich mal wenigstens zu fokussieren. Na ja, was soll ich dann machen? Also, wo stehen wir denn gerade? Was können wir besser machen, dafür gerade die Diskussion auch in diese Richtung zu lenken?
16:03
Ich habe zwar am Anfang gesagt, idealerweise kann ich das alleine machen. Aber im Endeffekt funktioniert diese Checkliste am besten, wenn man mit Leuten und vielleicht gerade einer erfahrenen Person darüber redet, um herauszufinden, was kann man denn in dem konkreten Bereich besser machen. Wo wir es auch, wir nutzen das eben auch für unsere Consultings, die wir auch intern machen,
16:22
um da einen Startpunkt eben auch zu finden. Oder wenn wir selber Software übergeben. Also, wenn derjenige bloß doch, auch wenn er nur noch einen Tag da ist, das nochmal einmal mit ihm durchzugehen, das kann schon mal einiges wenigstens noch halbwegs retten. Diese Empfehlungen kann man natürlich immer noch besser machen. Da gibt es immer noch verschiedene Punkte.
16:42
Auch in diesen Anwendungsklassen würde es helfen, noch mal klarer zu machen, was sind die Essentials? Was sind wirklich die Top-Prioritäten, die man auch nicht versuchen sollte wegzudiskutieren? Das müsste man auch machen. Und natürlich gibt es da Abhängigkeiten. Wenn ich den Leuten, wenn er irgendwie steht, na ja, für so eine Firma Continuous Integration ein, das funktioniert natürlich nicht, wenn ich keinen Version-Control habe,
17:02
wenn ich meine Software nicht automatisiert bauen kann und wenn ich vielleicht keine Tests oder sowas habe. Das müsste man noch ein bisschen transparenter machen, auch wenn wir das schon mit Verlinkungen gemacht haben, aber dass das noch ein bisschen klarer wird. Weil tatsächlich, es gibt so, manche wollen gar nichts manchmal machen und manche wollen plötzlich alles machen. Und denen muss man dann eigentlich eher helfen, gerade den Letzteren,
17:21
dass sie nicht enttäuscht werden von dem, dass sie nicht alles auf einmal machen können, sondern sie langsam halt ranführen sozusagen. Genau. Wichtig, damit sowas funktionieren kann, ist aber eigentlich diese ganze Umgebungsparameter. Das heißt, man braucht dann schon an einem Forschungszentrum halt eben auch eine passende Umgebung. Ich muss jemanden fragen können, so das Einfachste.
17:40
Das heißt, wichtig sind gerade so die Community im jeweiligen Institut, übergreifend im DLR, wie ist die Teamkultur und natürlich tatsächlich auch diese Policy-Gedanke. Also das ist, dass die Chefs wissen, dass das ein wichtiger Punkt ist. Sollten wir nicht vergessen. Aber für die Umsetzung der solcher Empfehlung ist natürlich wichtig,
18:01
dass ihr in der Umgebung, da habt ihr die Leute einfach nutzen können. Dass ein GitLab-Server zur Verfügung steht, auf den ich einfach meine Dinge bringen kann. Dass es vielleicht auch ergänzende Angebote gibt, die dann eben zeigen, wie sollen denn diese Empfehlungen umgesetzt werden. Wie arbeite ich vernünftig mit GitLab, mit drei, vier Leuten im Team zum Beispiel zusammen, insbesondere mit Git.
18:20
Es gibt auch ganz unterschiedliche Möglichkeiten. Gut, hier als letztes nochmal so ein paar Beispiele von uns. Das hier ist eher so ein Gremium. Also wir sind tatsächlich auch in Kontakt mit den verschiedenen Instituten. Wir haben einen sogenannten Ansprechpartner zum Thema Softwareentwicklung. Und die Aufgabe desjenigen ist natürlich, das Thema im Institut weiterzutragen und weiter voranzubringen.
18:44
Also das ist wie so eine kleine sternförmige Struktur ist das Ganze. Sodass wir selber im Austausch bleiben, aber auch überhaupt die Möglichkeit haben, solche Dinge zu verteilen und ins Bewusstsein zu rufen. Und die müssen natürlich auch eher gucken, wie kriegen sie ihre Community, wie kriegen sie ihre Softwareentwickler dann im Institut sozusagen in die Richtung mit.
19:01
Das ist halt so mit deren Job. Wir versuchen das dann mit unserer zentralen RSE-Gruppe eher übergreifend halt eben zu machen. Und ein Mittel davon sind dann halt eben diese Wissenaustauschworkshops zum Softwareengineering. Die Kreuzchen, das sind die sechs Stück, die wir jetzt schon gemacht haben. Wir machen so ein pro Jahr. Das sind so Veranstaltungen, die gehen über eineinhalb Tage mit Networking und immer zu einem anderen Hauptthema, aus dem Thema Softwareentwicklung.
19:23
Letztes Mal war man in Jena zum Thema Softwareengineering for Data Science. Hat auch zum Institut dort gepasst für Datenwissenschaften. Und da kommen auch Externe mit rein. Hat man auch von der Uni Jena eine schöne Keynote gehabt. Und ja, das ist auch ein sehr effizientes Mittel. Da kann man ungefähr 50 bis 60 Leute kommen.
19:41
Das ist eigentlich ganz gut und läuft jetzt schon seit sechs Jahren. Das ist in Ordnung. Das ist aber auch wichtig für diese Gesamtstruktur, um die Leute zusammenzubringen. Natürlich ein Platz, wo man Informationen austauschen kann im Wiki-Bereich. Da muss auch ein bisschen mit moderiert werden. Das sind so Sachen, die wir halt machen. Toolumgebungen, klar so was wie in GitLab. Das gibt es an verschiedenen Stellen in DDR. Und auch eine zentrale Variante ist da in der Mache.
20:03
Und halt eben auch angepasste Trainings, die zur Empfehlung und den Werkzeugen passen. So, dann bin ich eigentlich zum Schluss. Also diese Softwareengineering-Empfehlungen, die haben halt so einen bestimmten kleinen Fokus. Also sie können, sie helfen halt mit, ein Stück weit Forschungssoftware besser zu machen,
20:20
weil sie halt eine gewisse Orientierung geben. Bei CW hilft das uns auch, natürlich gewisse Dinge, die wir in der Unterstützungsumgebung hier machen wollen, auch natürlich entsprechend zu begründen. Also, warum brauchen wir diese, die Tools? Na ja, weil wir die und die Praxis unterstützen wollen. Das ist auch ein sehr guter Argumentationsverstärker dadurch, dass das in unserer Policy mit auch drin ist. Und das haben sie ja auch abgenickt.
20:40
Genau, aber wie gesagt, diese Umgebung ist eigentlich der Schlüssel, um eine bessere Praxis im Forschungszentrum. Gerade, wenn es so verteilt ist wie bei uns halt eben, hinzubekommen. Genau, die ständigen nächsten Schritte sind tatsächlich natürlich, diese Empfehlungen zu verbessern und diese ganze Umgebung. Also, damit ist man erstmal die Fertigeste. Sondern es machen alle perfekt, tolle Software. Das wird noch ein bisschen dauern.
21:01
Gut, genau. Wer da noch ein bisschen mehr sich das mal angucken möchte, wir haben so eine Webseite rse.de gemacht. Da findet man auch noch eine HTML-Version der Empfehlungen. Da kann man sich auch Checklisten als Mark daumen, beispielsweise mal runterladen. Wir haben diese Empfehlungen in Deutsch und Englisch auch in Form von einem PDF auf Zenodo veröffentlicht. Genau, und das war's schon.
21:21
Und ich bedanke mich für eure Aufmerksamkeit. Dankeschön. Fragen? Oder sind alle jetzt mit Empfehlungen soweit bescheid, dass jeder perfekte Software entspricht? Nein, das passiert nicht. Die Umgebung ist unglaublich wichtig.
21:43
Er hat für ein Versionenteam, dass ihr eigentlich sehr zentral für alle DLR-Institute zuständig seid. Erzähl. Wie siehst du das? Da gibt es sicherlich Vor- und Nachteile zwischen einer sehr zentralen und einer dezentralen. Ihr habt ja diese Umgebung,
22:00
wenn ich es richtig verstanden habe. Siehst du jetzt den Vorteil von dieser zentralen Lösung? Oder was denn da heißt sie? Die Frage war nochmal, das sieht ja erst mal relativ zentral organisiert aus und passt das so? Oder was sind so die Vor- und Nachteile, wenn ich es richtig verstanden habe?
22:22
Wir haben tatsächlich hiermit angefangen, aber das ist halt nicht alles. Das muss man halt sagen. Du musst halt eben auch diesen Community-Aufbau zwischen den Leuten, die Software entwickeln und nicht nur die, die das jetzt im Institut vorantreiben sollen, hinbekommen.
22:40
Und das brauchst du halt eben auch als Ergänzung. Und das ist halt eben auch gerade der Punkt, den wir zum Beispiel mit solchen Wissensaustausch-Workshops zum Beispiel adressieren. Und auch im Wiki kommen mittlerweile ganz von Leuten, die ich nicht kenne, Beiträge mit rein. Du musst das versuchen mit unterschiedlichen Möglichkeiten, wie vielleicht auch mal, wir haben da bestimmt noch Luft nach oben, deswegen, das ist nicht nur Spaß gemeint,
23:00
dass wir das verbessern müssen, sowie so eine Sprechstunde und so weiter. Aber der Vorteil ist halt, wir haben tatsächlich dafür Funding im DDR bekommen, das zentral ein Stück weit anzuschieben. Aber das schaffst du natürlich nicht, weil du musst ja die Leute bis in den Zentren eben erreichen. Das ist eine Stückweite Ernährung bei dieser SE-Netzwerkgedanke, aber du musst es noch mehr in Richtung Community-Aufbau letztendlich gehen.
23:22
Aber du brauchst halt beide Sachen so. Hier kommt so ein bisschen eher so am Anfang eher von der Policy-Geschichte, aber auch dieser Bottom-Up-Ansatz. Und das musst du gucken, wie du das austarierst für deine Organisation, in der du halt bist. Da gibt es nicht das Patentrezept. Okay, noch Fragen?
23:43
Mich würde interessieren, wenn du das am Anfang die Entwicklung der Policy am DLR erwähnt, insbesondere der Aspekt oder die Situation, wenn man jetzt auf der einen Seite die Frage hat, welche Zeit investiere ich im Modell Weiterentwicklung, um es dann wirklich auf einen Qualitätsstandard zu bringen, der nützwertig ist, oder auf der anderen Seite der Druck zu publizieren. Weil die eine Zeit fehlt
24:01
natürlich beim anderen. Und die Frage, wie wird sowas im Sinne von Credits denn auch gewürdigt, wenn man viel Zeit in die Modellverbesserung steckt? Das ist eine ganz gute Frage. Also es ging eher so um den Credit und die Anerkennung, sozusagen. Bei Papern ist das ganz klar.
24:21
Richtig. Also Policy-Entwicklung, das hört sich jetzt so rein intern an, aber ich denke, auch extern sind wir mittlerweile auch mit aktiv, sei zum Beispiel auf Helmholtz-Ebene. Weil das genau, dieses Thema Anerkennung, glaube ich, das knackst du nicht so in deinem Zentrum alleine. Du kannst ja natürlich einen tollen Qualitätspreis ausdenken und sonst was, aber das hilft im Endeffekt auch nicht. Ich glaube eben auch,
24:42
dass uns tatsächlich aber genau diese RSE-Zwischenrolle fehlt. Dieser akademische Mittelbau, den gibt es nicht in der Form. Und der müsste eigentlich mit aufgebaut werden. Und die haben dann ein ganz anderes Credit-System. Das ist dann vielleicht gar nicht so die Publikation. Bis hin natürlich, dass man natürlich auch Software publizieren kann, zitieren kann. Da wirken wir auch
25:01
schon hin. Auch zum Beispiel in unseren Trainings, das kam jetzt hier noch nicht so rüber, aber haben wir das eben auch in so einem Start-Training haben wir das auch eben verankert. Wenn ich schon auf GitHub veröffentliche, ist dann vielleicht noch in Richtung Zenodo zu bringen und mir eine DOI zum zitieren zu besorgen. Das ist dann noch ein Schritt sozusagen
25:21
drüber. Aber letztendlich glaube ich, dass wir das nicht mehr im Zentrum hinbekommen, sondern wir müssen eher so als Forschungsgemeinschaft so generell überlegen, wie wir das angehen. Ob das eine andere Rolle ist oder ob es da Alternativen gibt. Deswegen ist so Policy-Entwicklung wichtig, gerade auch außerhalb des Zentrums. Wir haben morgen noch einen kleinen Workshop
25:41
dazu. Das war einer der Gründe, um da rauszugehen, by the way. Was habt ihr bisher an Feedback bekommen von den Leuten, die das einsetzen müssen und wisst ihr nicht die Leute, die sich daran halten?
26:00
Du musst dich ja nicht daran halten. Die Frage war, wissen wir, wie viele Leute das schon einsetzen und wie viele sich daran halten, sozusagen. Genau, das Feedback. Wir kriegen Feedback aus unterschiedlichen Richtungen, weil wir das in unserer Qualitätspolitik mit drin haben. Das habe ich noch nicht bekommen, weil wir machen auch solche internen
26:21
Runden, wo externe Institute auditiert werden. Das ist so eine Quelle. Das konnte ich leider noch nicht anzapfen, das Feedback. Aber über unser SE-Netzwerk, das hängt immer natürlich von den Ansprechpartnern letztendlich und von den jeweiligen Instituten ab. Es gibt da Institute, die sind da sehr firm drinne und die
26:40
nutzen das gerade im Dialog miteinander. Die, die sich das angucken, die sagen schon, dass das denen hilft, dass überhaupt mal einen Leitfaden, das ist ja eigentlich die Idee, wo sie sich dran lang hangeln können. Wir kriegen auch positives Feedback dazu. Wir haben aber noch keine Erhebung gemacht, wie viele
27:02
Nutzen das genau. Da habe ich halt keine Zahlen zu. Aber das wäre vielleicht auch noch mal ein gutes Thema für eine nächste Umfrage beispielsweise. Das nehme ich auf jeden Fall mal mit. Okay. Genau. Aber da fehlen mir
27:25
gewisse Infos, aber das ist Teil von unserer Qualitätspolitik und die R-Institute quasi die so 9000 zertifizierungsfähig sein müssen, wenn ihr auch jährlich auch tatsächlich prüft in der Form und da wären genau diese Punkte halt nicht abgefragt.
27:41
Das Feedback habe ich noch nicht aufbereitet bekommen. Aber dazu würde mich auch interessieren. Du musst halt natürlich von einer anderen Warte gucken. Also wir haben ja auch so eine Umfrage jetzt neulich gemacht. Da haben wir das noch nicht mit eben integriert, weil wir erstmal so den Stand der Praxis, weil du kannst auch ohne, dass du sagst, ich kenne dir die Empfehlung, kannst du ja
28:01
den Stand der Praxis beurteilen. Also nutzen die Leute Version Control beispielsweise. Das ist eher eine andere Ebene, auf der man so ein Feedback bekommt. Ob das jetzt die Ursache dieser Empfehlung ist, das kannst du ja nicht ziehen. Aber das ist ja egal, um ehrlich zu sein. Sondern es zählt nachher die Entwicklungspraxis, die etabliert ist oder nicht etabliert ist.
28:24
Das haben wir, aber wir haben auch ganz viele anderen noch. Also jedes Institut hat da schon auch selber Sachen. Wir bieten aber auch zentrale Sachen an und ja, gerade weil so Infrastruktur in so einem doch größeren Laden ist, das ist gar nicht manchmal so einfach. Das kann ich euch
28:42
sagen. Hier war noch eine Frage. Die Checkliste mal für das Projekt die Empfehlung entwickeln ausgefüllt und das mal rausgegeben? Nee, haben wir noch nicht gemacht. Aber könnte man fast machen, weil ich sag mal diese Empfehlungslisten und diese Checklisten, die rausgeneriert werden, das haben wir auch in einem GitGitLab Projekt gemacht. Das ist im Prinzip ASCII-Doc,
29:02
was wir dann benutzen und haben dann halt eben auch diese Checklisten in Word, Markdown und Co. und auch dieses Gesamt-PDF, was es ja auch gibt. Das wird halt eben mit ein paar Python-Skripten rausgebracht. Also wir würden schon, glaube ich, auf Anwendungsklasse 1 würden wir da schon kommen. Wir machen schon sowas wie Tags und das Ganze,
29:21
wir haben uns ein kontinues Bild dafür mit aufgesetzt, weil sonst wirst du ja, sonst kannst du das ja nicht machen. Wenn du überlegst, das sind wirklich bestimmt 5, 6, 7 abgeleitete Dokumente, die Information ist anders zusammengestellt, weil in den Checklisten hast du viel weniger drin, aber wenn du hast, das sind die richtigen Dokumente, dann kriegst du eine Automatisierung nicht hin.
29:42
Auch die HTML-Version für die Webseite. Kopf fliegt daraus.