Qualitätssicherung in der Softwareentwicklung

Softwareentwicklung kann eine undankbare Aufgabe sein. Nicht selten stehen Budgets in sechs- oder gar siebenstelliger Höhe auf dem Spiel, der Zeitdruck ist immens, und dazu kommt, dass Softwaresysteme hoch komplex sind. Die Zahl der gescheiterten Projekte ist legendär. So verzögert sich etwa die Auslieferung des neuen Superzugs Velaro D ICE 3 aufgrund der komplexen Elektronik und Software für die Leit- und Sicherheitstechnik immer wieder. Und Alitalia blamierte sich im Herbst, als aufgrund eines Softwarefehlers kostenlose Tickets via Internet zu ergattern waren. Ein weiteres Beispiel lieferte die Commerzbank, als sie EC-Karten ohne funktionierende PIN ausgab.

Aufwendige Code-Reviews

Eines der Hauptprobleme bei Entwicklungsprojekten: Es fällt allen schwer, Risiken im Code zu entdecken und rechtzeitig zu entschärfen. Frei nach Forrest Gump: Softwareentwicklung ist wie eine Pralinenschachtel. Man weiß nie, was man bekommt.

Informationen über problematische Stellen erhalten Entwickler, Projektleiter oder Qualitäts-Manager bisher oft nur im Rahmen manueller Code-Reviews. Das Problem: Die Ergebnisse sind zwar hilfreich, werden aber meist nur punktuell erhoben, da die Reviews mit einem hohen Zeitaufwand verbunden sind. Sollten zusätzlich Metrik-Tools zur Codevermessung verwendet werden, sind die Ergebnisse als ellenlange Excel-Listen mit zum Teil mehreren zehntausend Einträgen dargestellt. Handlungsbedarf aufgrund der großen Datenmenge und der fehlenden Priorisierung ist bei solchen Tools mehr als gegeben, zumal die Entwickler einfach nicht wissen, wo sie anfangen sollen, da der ganzheitliche Blick auf die geschriebene Software fehlt.

Dies will die Potsdamer Software Diagnostics ändern, indem sie einen anderen Ansatz verfolgt: Ihre Software soll Entwicklungsverantwortlichen eine Gesamtschau auf alle relevanten Informationen in Form von Softwarekarten liefern - inklusive Risiken im Code und allen Entwickleraktivitäten. Dazu werden alle zur Verfügung stehenden Quellen von projektrelevanten Daten ausgelesen, diese miteinander kombiniert und anschließend mit Hilfe von Data-Mining-Methoden in Echtzeit analysiert.

Analyse des Codes

Die wichtigste Datenquelle ist dabei der Quellcode, der auf seine Anpassbarkeit und Verstehbarkeit und damit auf seine Zukunftsfähigkeit hin vermessen wird. Eine weitere Quelle sind Repositorien beispielsweise für das Konfigurations- oder Änderungs-Management. In diesen sind alle Aktivitäten eines Entwicklers über die letzten Jahre gespeichert: welchen Code er geändert hat, wann und warum. Weitere Repositorien, die ausgelesen werden und zusätzliche Perspektiven auf das Softwareprojekt bieten, sind beispielsweise Issue- oder Bug-Tracking-Systeme. Ebenso einbezogen wird, welche Codeteile durch automatisierte Tests abgesichert sind und welcher Code überhaupt von den Endnutzern gebraucht wird - eine oftmals vernachlässigte, aber wichtige Information. Weiß man zum Beispiel, dass 30 Prozent des Codes in der Entwicklung zwar aufwendig mitgepflegt und weiterentwickelt werden müssen, aber aus Sicht der Nutzer irrelevant sind, so sollte man den unnützen Code aus der Software entfernen. Man spart mit einem Schlag 30 Prozent der Wartungs- und Anpassungsaufwände. So banal diese Erkenntnis auf den ersten Blick wirken mag - in der Praxis sind viele Unternehmen bislang wegen mangelnder Transparenz ihres Softwarecodes nicht dazu in der Lage.

Visualisierung der Probleme

Damit Verantwortliche einen genauen Einblick in ihre Projekte erhalten, soll das Analyse-Tool von Software Diagnostics auf Grundlage der gewonnenen Informationen tagesaktuelle Softwarekarten erzeugen. Ähnlich wie Echtzeit-Satellitenbilder zeigen sie den Status eines Entwicklungsprojekts an. So erfahren Projektleiter gesichert, an welchen Stellen sich korrupter Code verbirgt, wo sich die Problemherde befinden oder welche Codequalität Dienstleister liefern. Mit diesem Wissen können sie die begrenzte Zeit der Entwickler und Tester auf die kritischen Stellen lenken. Ohne dass zusätzliche Ressourcen eingesetzt werden, sinkt so das Risiko, dass das Projekt scheitert. (hi)