Wissenschaftliche Software-Entwicklung – was ist das?

Aus der klassischen Softwareentwicklung ist bekannt, dass man zu Beginn eines Projektes nicht alle Details des Geschäftsprozesses kennt und dass sich Anforderungen im Projektverlauf noch einmal ändern können. Aus solchen Erfahrungen heraus haben sich die «agilen und schlanken Softwareentwicklungsmethoden» wie Scrum und Kanban entwickelt, die Änderungen an den Anforderungen und neue Informationen über die Software, die man gerade schreibt, nicht als Störung betrachten,  sondern als Teil der Aufgabe akzeptieren und fest in den Prozess einbauen. Bei Software für Forschungsaufgaben wird dieser Ansatz allerdings wesentlich weiter getrieben als bei klassischen Geschäftsanwendungen und -datenbanken. Die ursprüngliche Form, wie in der Forschung ausserhalb der Informatik Software entsteht (dazu zähle ich hier der Einfachheit halber auch Datenbanken) ist, dass eine Wissenschaftlerin, vielleicht zusammen mit einem Kollegen, im Rahmen eines Forschungsprojektes und zeitgleich dazu eine Sammlung von Computerprogrammen erstellt, um Daten auszuwerten und Messungen und Beobachtungen zu speichern und nach bestimmten Kriterien zu vergleichen, zu filtern und weiterzuverarbeiten. Die Forscherin ist dabei als Softwareentwicklerin ihre eigene Kundin, was ihr viele Freiheiten gibt, ihre Entscheidungen bezüglich Anforderungen, Prioritäten und Zeitplan der Software jederzeit zu ändern. Sie berücksichtigt dabei für die Weiterentwicklung ihrer Programme jeweils das, was sie zuvor im Projekt über ihren Forschungsgegenstand gelernt hat. Vielleicht findet sie heraus, dass sie ihren experimentellen Ansatz ändern muss und ändert ihre Software entsprechend. Die Änderungen am Programm sind dann zunächst einmal selber experimentell, müssen sich erst im Fortgang der Forschungsarbeit als richtig oder falsch erweisen, und werden dann entsprechend angepasst oder verfeinert. Mit anderen Worten: die Software ist ein integraler Bestandteil des Forschungsprozesses. Im Vergleich zu dieser Methode der Softwareentwicklung wirken selbst agile Softwareentwicklungsprozesse schwerfällig.

Was hat das mit den Informatikdiensten zu tun?

Man könnte sich fragen, was all das mit den Informatikdiensten zu tun hat. Hier kommen zwei neuere Entwicklungen ins Spiel: Zum einen hat die Komplexität und Vielfalt der Programme bei  den datengetriebenen Forschungsansätzen ständig zugenommen und damit der Aufwand für ihre Erstellung und Pflege. Zum anderen verwenden heute deutlich mehr Forschungsbereiche computergestützte Ansätze, darunter auch solche, bei denen das Denken in Algorithmen und das Entwickeln von Software nicht zum Methodenkanon der Ausbildung gehört, sondern wo Computermethoden ein weiterer, zusätzlicher Methodenbereich sind, den ein Forscher einsetzt. Diese beiden Entwicklungen führen zu einem Bedarf nach Spezialisierung und Arbeitsteilung beim Schreiben wissenschaftlicher Software. Ein Teil der Software, die hier entsteht, ist Methodenentwicklung und damit selbst Gegenstand eigener Forschung im Bereich und weiteren Umfeld der Informatik und Computerwissenschaften. Ein grosser Teil der Software allerdings ist nicht an und für sich publikationswürdig und damit als Spezialgebiet für Forscher uninteressant, gleichwohl aber als Teil des Forschungsprozesses notwendige Voraussetzung für den Erfolg. Die Forschenden können nicht mehr alle Software, die sie als Teil des Forschungsprozesses brauchen (und die es nicht zu kaufen gibt), selber schreiben und pflegen, sondern brauchen professionelle Unterstützung von Softwareentwicklern, die das Umfeld und die Voraussetzungen wissenschaftlicher Softwareentwicklung verstehen und die sich darauf organisatorisch und mental eingestellt haben. Die ETH Zürich hat sich entschieden, diese Dienstleistung in der Abteilung SIS der Informatikdienste anzusiedeln und dort generell die IT-Dienstleistungen für die Forschungsunterstützung zu bündeln.

Scientific Software und Data Management

Die Gruppe «Scientific Software und Data Management» (SSDM) besteht aus Softwareentwicklern, die sich darauf spezialisiert haben, im komplexen und sehr dynamischen Forschungsumfeld Software zu schreiben, in enger Abstimmung und Zusammenarbeit mit den Forschenden. (Die hier geschilderten Beispiele stammen tatsächlich von den organisatorischen Vorläufern von SSDM, C-ISD und SyBIT.) Es kann sehr unterschiedliche Software sein, die da entsteht: Vollständige Programme, Frameworks oder einzelne Programm-Module, Software zum Management von Daten und Workflows, zur Durchführung spezifischer Analyseschritte, zur Visualisierung von Messergebnissen, zum Abfragen, Filtern und Vergleichen von Resultaten, zur Ansteuerung von Messgeräten und Robotern, zur Integration von Datenmanagementsystemen,  Workflowsystemen, Queuingsystemen von Rechenclustern oder Automationssystemen. Hier sind zwei Beispiele:

1. Für ein umfangreiches Forschungsprogramm wird ein System für das Resultatdatenmanagement und -austausch benötigt. Die Anforderungen der einzelnen Projekte des Programmes haben Gemeinsamkeiten, aber auch viele Besonderheiten. Die Gemeinsamkeiten kristallisieren sich erst im Laufe der Zeit klar heraus, die spezifischen Anforderungen müssen trotzdem zeitnah abgedeckt werden. SIS schreibt dafür in enger Zusammenarbeit mit mehreren Forschungsprojekten ein System, das die unmittelbaren Anforderungen erfüllt und die vorhersehbaren Unterschiede zwischen den Projekten abdeckt. Das System wird kontinuierlich funktionell erweitert und in Richtung eines Softwareframeworks weiterentwickelt, um Synergien zu nutzen und doppelte Arbeit zu vermeiden. Für die Benutzer ist das transparent, denn Synergien sind für sie nicht wesentlich, für die langfristige Wartbarkeit sind sie aber essentiell. Das System erweist sich nämlich als deutlich vielseitiger und langlebiger als das ursprünglich gedacht war: Labore benutzen es auch ausserhalb des Forschungsprogramms, für das es geschrieben war, wissenschaftliche Facilities an der ETH verwenden es, mehrere mittlere und grosse Firmen setzen es ein und machen Supportverträge mit der ETH, um von uns Unterstützung im Produktiveinsatz und Weiterentwicklungen zu bekommen. Entwickler an anderen Universitäten beginnen das Framework als Basis für eigene Entwicklungen zu verwenden, von denen eines seinen Weg zurück an die ETH findet.

2. Ein Doktorand schreibt ein komplettes Framework für die flexible Ansteuerung von automatisierten Mikroskopen basierend auf einem bestehenden Open-Source-System, das deutlich flexibler ist als die von den Mikroskopieherstellern gelieferten Softwaresysteme und Messprozesse erlaubt, die die Hersteller nicht vorgesehen haben und deshalb nicht unterstützen, obwohl die Hardware sie erlaubt. Der Doktorand hat einige Vorerfahrung in Programmierung und schreibt guten Code. Da es gute Arbeitsbeziehungen zwischen SIS und seinem Lab gibt, holt er sich bei Fragen zur Modularisierung, zur nebenläufigen Programmierung und zur Softwaretechnik (Versionskontrolle, Build-Systeme, kontinuierlicher Integration) Rat und Hilfe bei SIS-Softwareingenieuren. Das System bekommt eine Schnittstelle zum Upload von Mikroskopieaufnahmen in das unter 1. beschriebene Datenmanagentsystem, das in dem Lab verwendet wird. Wir beteiligen uns auf Anfrage an Diskussionen rund um das System, z.B. wie die interne Schnittstelle zu dem zugrundeliegenden Open-Source-Treibern verbessert und vereinfacht werden kann. Der Anlass dafür ist, dass die parallele Messung mit mehreren Kameras einen fehleranfälligen Hack erfordert, weil das in den Treibern nicht vorgesehen ist. Wir helfen beim Refactoring-Konzept, ein «Hiwi» beginnt mit dem nötigen Refactoring des Basissystems, kann es aber nicht abschliessen, aus Zeitgründen und weil ihm die Erfahrung dazu fehlt. Am besten wäre eine direkte Zusammenarbeit mit den Entwicklern diese Basissystems, aber die sitzen nicht gerade ums Eck, sondern an der University of California in San Francisco. Das Framework, das als «Hobby-Projekt» (im guten Sinn) eines motivierten Doktoranden begonnen hat, findet Anklang bei anderen Forschungsgruppen und eine Departments-Facility für Mikroskopie möchte es einsetzen. Wir raten an, das nur zu tun wenn die langfristige Softwarepflege sichergestellt ist, was ein Doktorand nicht leisten kann. Das Department möchte wissen, ob wir die Pflege und Weiterentwicklung des Systems übernehmen können, SIS-Softwareingenieure beginnen, sich in das System tiefer einzuarbeiten…

So könnte es ewig weitergehen…

Ich könnte viele weitere Beispiele nennen: Fragen von Forschern zur Beschleunigung von Algorithmen, zur Verbesserung der Parallelisierbarkeit (auf Rechenclustern), zur Verbesserung der Robustheit einer 24×7-Lösung, wenn das Netz zeitweilig ausfällt, Anfragen zur Erstellung von Web-Interfaces und Mobile-Interfaces von schon bestehenden Systemen und generell zur Visualisierung von Ergebnissen. Viele davon haben gemein mit den beiden Beispielen oben, dass die Entwicklung solcher Systeme alles andere als vorhersehbar oder planbar ist, dass es klein anfängt und, wenn es Erfolg hat, wächst und eine langfristige Pflege erfordert, und dass unabhängig voneinander entwickelte Module auf einmal zusammenarbeiten müssen. Hätte man am Anfang mit Verweis auf das mögliche Wachstum auf einem Projektplan oder einem Pflichtenheft bestanden, wäre das Projekt von Seiten der Forscher beendet gewesen, bevor es begonnen hat. Um in dieser Umgebung erfolgreiche Softwareprojekte machen zu können, braucht es vor allem Erfahrung damit, wie Software im Forschungsbereich entsteht und sich entwickelt, und wie Forscher mit Software arbeiten und über Software denken. Gegenüber der Situation, wo eine Forscherin ihre eigene Softwareentwicklerin ist (siehe oben), müssen sich natürlich auch die Wissenschaftler umstellen, denn um eine gewisse Koordination kommt man bei einer Zusammenarbeit nicht herum. In erster Linie ist es aber die Serviceabteilung, die sich auf die Forscher einstellen muss und nicht umgekehrt. Einige Leitlinien haben wir in diesem Umfeld gefunden, die sich als nützlich herausgestellt haben:

Nützliche Leitlinien

1. Warte nicht darauf, dass die Anforderungen und Lieferobjekte klar definiert werden, denn das wird nicht passieren. Fange an, mit dem was du weisst, und lasse es wachsen.
2. Sei dir klar, dass der enge Kontakt mit der Forschungsgruppe von Anfang an eine Erfolgsvoraussetzung ist. Oft startet man ein wissenschaftliches Softwareentwicklungprojekt am besten mit einem Softwareingenieur, der «eingebettet in die Forschungsgruppe» arbeitet.
3. Sei bereit, Entwicklungsprioritäten von neuen Features und Verbesserungen jederzeit schnell zu ändern, ohne aber die längerfristige Sicht auf Struktur und Wartbarkeit zu verlieren.
4. Führe neue Funktionen und Verbesserungen in einem schnellen und kontinuierlichen Prozess ein, in dem Entwickler, Server-Admins und die Forscher als Benutzer eng zusammenarbeiten und direkt miteinander reden. Das verhindert Missverständnisse und unnötige Arbeit.
5. Sei dir klar dass du erst später herausfinden wirst, welche Teile der Software nach einem halben Jahr passé sind und welche in verallgemeinerter Form für viele Jahre unterstützt werden müssen.
6. Wo es Übergänge zwischen Phasen der Softwareentwicklung gibt, z.B. zwischen einem Prototypen, einem Testsystem und einem Produktivsystem: mache das unsichtbar für die Forscher, aber habe ein Auge auf die tatsächliche Benutzung. Die Unterscheidungen sind für sie bedeutungslos, sie werden solange funktional und nicht-funktional iterieren bis sie zufrieden sind und das System dann umstandslos produktiv benutzen, auch wenn gross und  in roter Farbe «Prototyp» draufsteht. Backups von Testsystemen sind daher gar keine schlechte Idee.
7. Als Leiter eines solchen Software-Projektes, versetze dich in die Sichtweise der Forscher hinein; agiere als Co-PI («Principal Investigator») , nicht als Projektmanager.

Über Erfolgs- und Misserfolgsfaktoren von Softwareprojekte im wissenschaftlichen Umfeld findet man in der einschlägigen Literatur eher wenig. Das liegt daran, dass die Entwicklung wissenschaftlicher Software im grossen Feld der Softwareentwicklung und gerade auch im Vergleich zur Softwareentwicklung von Geschäftsanwendungen nur einen kleinen Nischenbereich ausmacht. Einen allerdings, der im Kernkompetenzbereich der ETH Zürich als forschungsstarker technischer Hochschule liegt.

Kontakt

DR. Bernd Rinn, Abteilungsleiter ID Scientific IT Services

Posted on 02.09.2013 by Sabine Hoffmann
in News, Software, Arbeitsplätze, Speicher, Support, Wissenschaftl. Rechnen Tags: Scientific IT Services, SIS, Softwareentwicklung, Wissenschaftliche Software-Entwicklung