Maschinelle Code-Inspektion und technische Erfahrung Wenn Mensch und Maschine aufeinander treffen

Ein »Feldtest« von PRQA mit Ingenieuren die C-Mustercode analysierten und ihre Ergebnisse mit denen aus einem automatisierten Code-Inspektionswerkzeug verglichen, zeigte, dass die Ergebnisse der manuellen Software-Inspektion subjektiv und stark von der allgemeinen Erfahrung des Ingenieurs sowie von dessen spezifischem Wissen des Codes abhängig waren. Der Einsatz einer automatisierten Code-Inspektion kann diese Ergebnisse erheblich verbessern und auch besser nutzbar machen.

Wissen spielt in einer Technologie-gestützten Industrie wie der Elektronik eine implizite Rolle, so dass Automatisierung oft skeptisch gesehen wird. Automatische Codegenerierung wird dagegen oft akzeptiert als ein gangbarer Weg zur Erfüllung der ständig zunehmenden Anforderungen nach tausenden von Codezeilen, die speziell für Anwendungsgebiete mit hohen Zuverlässigkeitsanforderungen für jedes neue Produkt erstellt werden müssen. Obwohl sie ähnlich viele Vorteile und Absicherungen bietet, kam die automatisierte Codeinspektion nicht so häufig zum Einsatz. Für frühe Phasen des Software-Lebenszyklus hat die Nutzung der Automatisierung erheblich zugenommen. Es scheint aber, dass viele Ingenieure eine Automatisierung entweder nur widerwillig einsetzen, oder nicht gut Bescheid wissen über ihre Vorteile in späteren Phasen des Entwicklungszyklus und speziell in der Softwarekontrolle-Projektphase.

Besonders die automatisierte Code-Inspektion kann den Prozess der Softwarekontrolle nicht nur beschleunigen, sondern auch deren Ergebnisse verbessern. Um dieses Potenzial zu verdeutlichen, findet jedes Jahr auf einer Entwicklerkonferenz ein Wettbewerb statt. Die Ingenieure sind dabei aufgefordert, sich so viel Zeit wie nötig zu nehmen und möglichst viele Fehler in einen Quellcode-Muster zu identifizieren. Sie können dann sehen, wie ihre Anstrengungen im Vergleich zu  den Ergebnissen eines automatisierten Werkzeugs abschneiden. Der diesjährigen Herausforderung stellten sich etwa 50 Entwickler, die ein echtes Interesse am Schreiben von hochqualitativem Code hatten. In der Regel kamen die Teilnehmer aus Organisationen, die hochqualitativen Code erstellen müssen oder sich darum bemühen. Obwohl die Quellcode-Probe klein war, entsprach sie der in früheren Wettbewerben bei der gleichen Veranstaltung verwendeten Probegröße. Die Ergebnisse des Wettbewerbs zeigen, wie die gesamte Branche von einer automatisierten Code-Inspektion mit statischen Analysewerkzeugen in den frühen Phasen einer Software-Analyse profitieren kann.

Den Anwendern wurde als Beispiel ein C/C++ Quellcode übergeben, der sich nachweislich fehlerfrei kompilieren ließ. Die Teilnehmer waren eine Gruppe aus Software-, System-, Software-Qualitätsingenieuren, Informatikern, Studenten sowie ein leitender technischer Ingenieur. Viele der rund 50 abgelieferten Ergebnisse enthielten Randnotizen, die die Tiefe des Fachwissens der Teilnehmer belegten. Besonders beeindruckend war dabei, dass viele der Tests auf dem Messestand innerhalb von 30 Minuten ausgeführt worden waren. Der gleiche Code wurde dann dem automatisierten, statischen Analysewerkzeug QA-C von PRQA Programming Research übergeben. Für die Analyse des Codes benötigte dieses Werkzeug nur wenige Sekunden. Natürlich war die für die Code-Analyse benötigte Zeit nie das Ziel der Demonstration, weil ja zu erwarten war, dass ein Softwarewerkzeug die Ergebnisse wesentlich schneller als ein Mensch liefern konnte. Das eigentliche Ziel der Gegenüberstellung war ein Vergleich der Ergebnisqualität.

Obwohl der Code von Anfang an kompilierbar war, konnten die Teilnehmer eine Reihe von Problemen identifizieren, wobei der Bestwert bei 33 lag - das automatisierte Werkzeug fand 120 Probleme. Hier geht es allerdings nicht um die Offenlegung der Ineffizienz der Ingenieure; vielmehr sollten die Ergebnisse drei Punkte verdeutlichen: die Begrenzungen von Compilern bei der Offenlegung von Fehlern und Problemen, die Variabilität, Ineffizienz und die Beschränkungen einer manuellen Code-Analyse und dementsprechend auch die Leistungsfähigkeit einer automatischen Code-Inspektion.

Um Fehler zu eliminieren, wurde das Analysewerkzeug so konfiguriert, dass es den verwendeten Compiler emulierte. Im vorliegenden Fall war dies Visual Studio 2008. Das Analysewerkzeug war außerdem so eingerichtet, dass es Kodierungs-Standards einer typischen Organisation implementierte, die strenge Anfangskriterien für formelle Code-Inspektionen verwendet.