Viele Katastrophen des Alltags beginnen mit diesem Satz: "Das bring ich noch mal schnell in Ordnung." Dass auch Profis gern mal aus dem Handgelenk arbeiten, bekommen Opfer streikender Computer zu spüren. "Programmierer führen ständig Softwareänderungen aus dem Bauch heraus durch", sagt Stephan Diehl, Informatikprofessor an der Universität Trier. "Wir haben festgestellt, dass viele gar nicht wissen, wie oft sie das eigentlich machen."
Ein gefährlicher Blindflug: Programme bestehen aus Tausenden von Modulen, die auf vielfältige Weise verbunden sind. Eine hastige Änderung kann das ganze Programm ins Chaos stürzen. Mit seinem Team entwickelt Stephan Diehl Instrumente, mit denen solche Schlampereien aufgedeckt und verhindert werden können.
Die Informatiker arbeiten fast wie Archäologen: Sie analysieren die digitalen Spuren, die Programmierer bei ihrer Arbeit hinterlassen. Zu jeder professionell gepflegten Software gibt es Datenbanken, in denen alle Änderungen am Code registriert werden. Diehls Analysewerkzeuge werten Tausende von Protokolleinträgen statistisch aus und machen das Verhalten des Programmierteams als bunte Grafiken sichtbar. Sie zeigen, ob zusammenhängende Programmteile gemeinsam gepflegt werden oder ob das Team ungeordnet vorgeht. Erkennen lässt sich auch, ob bestimmte Teile besonders oft geändert werden. Das wäre ein Hinweis, dass sie Schlüsselstellungen innehaben und Achillesfersen sein könnten.
Für Softwarefirmen sind solche Hinweise Gold wert. Programme und Betriebssysteme haben inzwischen solche Ausmaße, dass es unmöglich ist, jede Programmzeile auf Fehler zu prüfen. "Selbst Microsoft hat nur beschränkte Ressourcen", sagt Andreas Zeller, Professor für Softwaretechnik an der Universität des Saarlandes, "und die haben Turnhallen voller Rechner." Der Konzern erprobt derzeit, ob sich mit einem von Zellers Verfahren berechnen lässt, welche Teile des neuen Windows Vista wahrscheinlich geflickt werden müssen. Dafür wertete Zeller alle registrierten Fehler des Vorgängers Windows XP aus und berechnete, ob die maladen Teile gemeinsame Eigenschaften haben. Sein Werkzeug prüft nun, welche Teile von Windows Vista ebenfalls diese Eigenschaften aufweisen und damit ebenfalls verdächtig sind. "Implizit war den Managern bekannt, wo die meisten Fehler auftreten", sagt Zeller. "Aber Häufigkeiten systematisch auszuwerten, darauf waren die noch nicht gekommen."
Seit den 90er-Jahren existieren Methoden für das Auswerten von Softwareentwicklungsarchiven, in der Fachwelt als Mining Software Repositories (MSR) bezeichnet. Doch bis vor Kurzem konnten nur wenige Informatiker diese Methoden in der Praxis testen. Softwareentwicklung fand in Unternehmen hinter verschlossenen Türen statt. Den Wandel brachten erst Projekte wie das Betriebssystem Linux oder der Internetbrowser Mozilla, deren Daten frei zugänglich sind. "An den Open-Source-Projekten konnten wir Verfahren entwickeln und beweisen, dass sie funktionieren", sagt Zeller. MSR ist inzwischen in der Informatik etabliert. Forscher stürzen sich auf alle Spuren der Programmierer. Sogar ihre E-Mails werden analysiert, um das Sozialverhalten erfolgreicher Teams zu erkunden.
Am Wert solcher Analysen zweifelt Dieter Rombach, Leiter des Fraunhofer-Instituts für experimentelles Software-Engineering. Für sinnvoll hält er dagegen die Analyse von Programmcodes: Sie könnte Regeln für die Arbeit der Programmierer ergeben, so wie Regeln für Maschinenbauingenieure durch die Physik definiert werden. "Wir finden gerade viel darüber heraus, was Codes fehleranfällig macht", sagt Zeller. Vieles ist noch Grundlagenforschung, doch das Interesse der Industrie wächst. "Bisher hilft uns die statistische Analyse von Software Repositories kaum bei der Voraussage fehleranfälliger Produkte", sagt Günther Limböck, Vice President Global Quality Governance bei SAP. Zwei mit Zeller durchgeführte Projekte hätten aber wertvolle Hinweise geliefert, denen er in einem gemeinsamen Folgeprojekt nachgehen will: "Das Potenzial von MSR ist noch lange nicht ausgeschöpft."