Statische Codeanalyse und Testabdeckungsmessung bezogen auf die Codebasis ist zwar als Mittel der Qualitätssicherung bekannt, wird aber insbesondere bei Software im nicht-regulativen Bereich eher selten eingesetzt. Oft wird der Aufwand im Vergleich zum Nutzen bezweifelt oder die Einführung wird versucht, scheitert aber oft nach einer gewissen Anfangseuphorie.

Wenn mit der Einführung gar nicht erst begonnen wird, wird oft das Argument gebracht, dass man dafür keine Zeit hätte, es andere wichtigere Themen gäbe und das ja gar keine Probleme mache (die man allerdings in späteren Projektphasen bei älterem Bestandscode sehr wohl merkt...). Hier ist also das typische „keine Zeit für den Zaun, da mit Hühnerfangen beschäftigt“–Phänomen zu beobachten.

Grund für ein Scheitern im Betrieb ist oft die Art der Einführung: Nach der Anschaffung des Tools (gerne auch mit Herstellerunterstützung) wird versucht, eigenständig ohne viel Aufwand eine große Zahl an Findings durch Aktivierung möglichst vieler Regeln (oft will die QS sowas...) aufzuzeigen.

Die Entwickler fühlen sich von der großen Zahl der Findings überschwemmt (wo sollen wir anfangen..., was machen wir mit den bestehenden Findings..., wie arbeiten wir uns vorwärts..., viele Findings bringen uns gar nichts, da wir so nie programmiert haben...). Sind dann noch eine nennenswerte Anzahl der Findings aus Entwicklersicht „False Positive“, sinkt der Spaßfaktor an dem Einsatz der statischen Codeanalyse ins Bodenlose.

Fragt dann noch das Management auf Grund der gut gefüllten Dashboards, warum es so viele Probleme im Sourcecode gäbe und warum die Meldungen sich nicht verringern oder gar was das alles solle (...der Code würde doch funktionieren...), weicht auch bei den letzten Beteiligten die Begeisterung einer deutlich steigenden Urlaubssehnsucht. Da aber Urlaub leider zu kurz ist und nicht allgemein als Problemlösung akzeptiert ist, soll an Hand eigener leidvoller Erfahrungen aber auch Erfolge die Lessons Learned aus der Einführung statischer Codeanalyse-Tools für mehrere Projekte vermittelt werden.

Hierbei soll insbesondere auch aufgezeigt werden, welche Punkte bei einer Einführung der statischen Codeanalyse in verschiedenen Projekten (in Projekt mit ca. 3 Millionen Zeilen C++ Code, teilweise 20 Jahre alt, Teamgröße ca. 30 Entwickler) beachtet werden müssen. Es darf zwar keine wissenschaftliche allgemeingültige Abhandlung erwartet werden, sondern aus eigenen leidvollen Erfahrungen aber auch Erfolgen geprägter Erlebnisbericht mit entsprechenden Schlussfolgerungen.

Die gemachten Erfahrungen sollen einem breiten Interessentenkreis zugänglich gemacht werden, um die eigene Einführung von Beginn an erfolgreich gestalten zu können und einen Erfahrungsaustausch zu ermöglichen (vielleicht kommt es dem einen oder anderen bekannt vor oder es gibt auch ganz andere Wege, sowas zu machen…
was wiederum auch für den Referenten interessant wäre…).

Die Lessons Learned umfassen dabei insbesondere die folgenden Punkte:

• Vorleistung durch „Nichtentwickler“ (z.B. QS)
• Herstellervorführungen von Tools
• Tool-Evaluation
• Einführungsphase des Tools inklusive Zusammenarbeit mit der Entwicklung und Unterstützung durch den Toolhersteller
• Einbinden in den Build-Prozess
• Konfiguration der Regeln
• Beteiligung der Entwicklung bezüglich Einführung eines neuen Tools
• Prüfen der Findings durch Entwicklung und Konfiguration der Regeln
• Umgang mit Meldungen in bereits bestehendem Code