Business Intelligence für Softwaresysteme

Anbieter zum Thema

netfiles GmbH

Hyland Software Germany GmbH

Cloudgermany.de GmbH

Objektive Projekt-Informationen in Echtzeit

Software Diagnostics, ein Spin-Off des Hasso-Plattner-Instituts in Potsdam, hat auf der Basis von Software Mining ein unternehmensweites Echtzeit-Informationssystem für den Bereich Software-Entwicklung und -Maintenance geschaffen, die Lösung Software Diagnostics Server.

Eine integrierte Software-Intelligence-Plattform erlaubt es Managern und Teamleitern, je nach Zugriffsrecht, Software-Entwicklungs- und Maintenance-Prozesse zu überblicken und Adhoc-Anfragen an das System zu stellen. Bei Bedarf kann direkt in den Sourcecode gewechselt werden. Werden zusätzlich Daten aus Enterprise-Software wie SAP miteinbezogen, eröffnen sich noch weitere Möglichkeiten für die Projektsteuerung. Kostenstellen, Stundenlöhne und Entwicklungsstunden pro Projekt-Milestone und Kunde werden dabei mit den Daten aus dem Softwaresystem in Beziehung gesetzt und in einer Software-Lagekarte aufgetragen.

Was Software-Lagekarten für die Projektsteuerung tatsächlich leisten können, zeigt sich unter anderem bei der Qualitätssicherung. Mit hoher Testabdeckung in einem Softwaresystem können sich die Verantwortlichen längst nicht mehr zufrieden geben, denn dass der Code am Ende des Projekts funktionstüchtig ist, bedeutet nicht zwangsläufig, dass er das auch in Zukunft sein wird.

Wenn die Software beispielsweise um neue Features ergänzt werden soll, können Arbeiten an unübersichtlichen Strukturen unerwünschte Nebeneffekte erzeugen und zum echten Problem werden. Ein wichtiger Faktor für gute Wartbarkeit und somit niedrige Folgekosten ist darum eine saubere Implementierung. Ein Blick in das Softwaresystem mithilfe der passenden Software-Lagekarte zeigt, wie es um die Qualität des Codes tatsächlich bestellt ist. In der Ansicht „Code Quality Map“ (Abb. 1 in der Bildergalerie), hier gezeigt am Beispiel des JBoss Application Servers von Red Hat, sind riskante Komplexitäts-Hotspots leicht zu erkennen.

Software-Lagekarten zeigen Schwachstellen und Entwicklungsbremsen auf

Die Anordnung der grauen Flächen entspricht der Architektur des Softwaresystems und die Grundfläche der einzelnen Formen der Anzahl an Lines of Code. In der Höhedimension ist die McCabeComplexity ausgewählt, eine Metrik, die die Komplexität eines Moduls angibt. In Kombination mit dem Grad der Kontrollfluss-Verschachtelungstiefe, erkennbar anhand des Farbschemas, wird klar, welche Module dringend einem Qualitätscheck und gegebenenfalls einem Refactoring unterzogen werden sollten: Die Module, die als hoher roter Balken angezeigt werden, weisen bei beiden Metriken auffällige Werte auf und sind offenbar unübersichtlich aufgebaut. Ist die Grundfläche der Balken relativ groß, ist dies ein weiterer Hinweis auf ein Qualitätsrisiko, denn es handelt sich um große, vermutlich monolithisch gewachsene Dateien mit unklarer Struktur. Sie sollten genauer untersucht und gegebenenfalls verändert werden, da sie eine latente Gefahr für die Funktionstüchtigkeit und Weiterentwicklung des Systems darstellen.

Für den Erfolg eines Projekts spielt natürlich nicht nur die Qualität sondern auch der Faktor Zeit eine entscheidende Rolle. Mit der passenden Software-Lagekarte erkennen Projekt-Verantwortliche rasch, welche Module sich über einen bestimmten Zeitraum als regelrechte Entwicklungsbremse manifestiert haben. Die Höhe der Balken in der „Team-Performance-Map“ (Abb. 2 in der Bildergalerie) gibt die Anzahl der Änderungen an einer Datei an. Sind die Türme rot, bedeutet dies, dass dabei mindestens vier Entwickler am Werk waren. Bei zahlreichen Änderungen von vielen unterschiedlichen Entwicklern ist es höchste Zeit, genauer hinzuschauen, denn offenbar investiert das Team viel Zeit und Energie in die Veränderung dieser Dateien. Mit dem Wissen aus den Software-Lagekarten kann der Projektmanager die nächsten Schritte angehen, um die Ursachen mit den betreffenden Kollegen zu analysieren und idealerweise zu beseitigen. Mit weiteren Abfragen kann das Team die besonders häufig geänderten Module außerdem genauer auf typische Problemquellen, wie beispielsweise Code-Duplizierung überprüfen und die Position der Datei in der Software-Architektur besprechen.

weiter mit: Frühwarnsystem ermöglicht aktives Projektmanagement

(ID:2052937)