2011_6 Software Diagnostics Software Mining Software-Lagekarten
|
|
|
»manage
it«
als
|
Wie Software-Lagekarten die notwendigen Entscheidungshilfen liefern, um Projektklippen sicher zu umschiffen Softwareprojekte auf Kurs halten Während der Luxusliner am 14. April 1912 mit voller Fahrt voraus den Nordatlantik durchpflügte, genoss Edward John Smith die Dinner-Party. Von diversen Wettermeldungen, Eiswarnungen und Eisbergsichtungen hatte Smith kaum etwas erfahren, so dass der Kapitän der Titanic schließlich in aller Ruhe zu Bett ging – mit den bekannten Folgen. Noch heute ist mangelnde Information der Entscheidungsträger die häufigste Ursache, wenn Unterfangen scheitern. Dabei stehen mit der neuen Disziplin des Software Minings inzwischen auch den Verantwortlichen in Softwareprojekten die notwendigen Werkzeuge zur Verfügung, die Fehlentwicklungen rechtzeitig erkennen lassen und sie darin unterstützen, die richtigen Maßnahmen zu treffen. Aussagekräftige Software-Lagekarten, basierend auf neuartigen Extraktions- und Analyse-Verfahren und einer leistungsfähigen Visualisierung liefern dafür die entscheidenden Informationen.
enn es darum geht, betriebswirtschaftliche Kennzahlen aus unterschiedlichen Quellen auszuwerten und Entwicklungen im Unternehmen zu analysieren, setzen Manager schon lange auf Data Mining und Business-Intelligence-Lösungen. Hier sind auf Knopfdruck zumindest ausführliche Auswertungen als Tabellen oder aussagekräftige Grafiken zu erhalten, als State-of-the-art gelten mittlerweile gar Management-Dashboards mit Echtzeit-Alarmierung per SMS, sollten die Sollwerte einmal aus dem Ruder laufen. Verantwortlichen von Softwareentwicklungs- und Wartungsprojekten, die ihre Kosten- und Risikofaktoren ebenfalls im Auge behalten müssen, bleibt dagegen bislang nur ein Weg, um den Zustand, die Entwicklung und den Fortschritt des Softwaresystems, an dem gearbeitet wird, zu überblicken und Schwierigkeiten rechtzeitig zu erkennen und einzuordnen: die subjektive Einschätzung der einzelnen Entwickler einzuholen. Denn das Softwaresystem selbst, so viele betriebswirtschaftliche Risiken es auch enthalten mag, entzieht sich jedem Einblick durch das Management. Dies zu ändern ist der Anspruch von Software Mining. Dazu will die neue Disziplin die »Sourcecode-Wirklichkeit« in Software-Entwicklungs- und Maintenance-Projekten in geeigneter Form aufbereiten, um dem Management gesicherte Entscheidungsgrundlagen zu geben. Business Intelligence für Softwaresysteme Software Mining extrahiert und analysiert dazu automatisch alle nutzbaren Informationen aus dem vorhandenen Quellcode, einer dynamischen Laufzeitanalyse sowie den eingesetzten Repositorien,und Lösungen für den Bereich Software Qualität und Maintenance des Softwaresystems, verdichtet diese und setzt sie miteinander in Beziehung. Der Programmcode wird dabei nicht verändert. Eine grafische Visualisierung macht die Informationen aus dem System schließlich für den Menschen intuitiv erfassbar und zeigt Zusammenhänge auf. Das Ergebnis sind dreidimensionale Software-Lagekarten, die den Aufbau und Zustand eines Softwaresystems als großes Ganzes zeigen und mit denen sich die bestehenden Lücken im Projektmanagement schließen lassen. Die Stärken des Software Minings kommen um so mehr zum Tragen, je größer und komplexer die Systeme sind, an denen entwickelt wird. Bei 50.000 Lines-of-Code oder Teams von mehr als drei Entwicklern ist ohne ein leistungsfähiges Informationssystem kein Überblick mehr möglich, von gezielter Projektsteuerung ganz zu schweigen. Die Software-Lagekarten indessen machen ein System mit seiner Architektur und seinen Entwicklungsprozessen in seiner Gesamtheit sichtbar. Das auf diese Weise aus dem Softwaresystem gewonnene Wissen liefert der Unternehmensführung wertvolle Entscheidungsgrundlagen über den gesamten Lebenszyklus eines Softwaresystems hinweg und unterstützt sie dabei, das eigene Entwickler-Team, möglicherweise an verschiedenen Standorten, oder externe Partner zielgerichtet zu steuern. Mit dem neuen Verfahren können nicht nur selbst entwickelte, sondern auch wenig bekannte, zugekaufte und zugelieferte Code-Teile durchleuchtet werden. So werden die Projektrisiken erheblich gesenkt. 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. Qualitätsschwächen und Zeitfresser auf den ersten Blick erkennen 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), hier gezeigt am Beispiel des JBoss Application Servers von Red Hat, sind riskante Komplexitäts-Hotspots leicht zu erkennen. 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 stellen somit eine latente Gefahr für die Funktionstüchtigkeit und Weiterentwicklung des Systems dar und sollten genauer untersucht und gegebenenfalls verändert werden. Neben der Qualität spielt natürlich auch der Zeitplan für den Erfolg eines Projekts eine maßgebliche 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) 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 Karten kann der Projektmanager die nächsten Schritte angehen, um die Ursachen mit den betreffenden Kollegen zu analysieren und gegebenenfalls zu beseitigen. Mit weiteren Abfragen kann das Team die besonders häufig geänderten Module außerdem weiter auf typische Problemquellen, wie beispielsweise Code-Duplizierung überprüfen und die Position der Datei in der Software-Architektur besprechen. Lessons learned garantiert Die Software-Lagekarten unterstützen folglich verschiedene Herangehensweisen an die Überwachung eines Projekts: Manager können Code-Monitoring betreiben, indem sie regelmäßig bestimmte Werte – beispielweise Metriken – und Zusammenhänge abfragen und auf Auffälligkeiten prüfen. Ausgestattet mit diesen Erkenntnissen können sie die nächsten Schritte einleiten, um Verbesserungen für das Projekt zu erreichen. Umgekehrt können sie aber auch nach der Ursache bestimmter Phänomene forschen, die sie stutzig machen. Steht den Entwicklern ein Issue/Bug-Tracking-System zur Verfügung, können die Manager etwa gezielt Dateien anzeigen lassen, an denen Bug fixes durchgeführt wurden (Abb. 3). Die Software-Lagekarte gibt dann nicht nur Aufschluss darüber, in welchen Modulen Bug fixes gehäuft aufgetreten, sondern auch, wie hoch an diesen Stellen die Komplexität und der Grad an Code-Duplizierungen war. Um zeitraubende Nacharbeiten beim nächsten Projekt zu minimieren, kann der Manager bei der Teamführung und beim Monitoring in Zukunft verstärkt auf diese Faktoren achten. Durch den Einsatz von Software-Lagekarten wird transparent, wo ein Projekt zu einem bestimmten Zeitpunkt wirklich steht, und es werden »Zeitbomben« im Code sichtbar, die der Projekt-Verantwortliche rechtzeitig in den Fokus nehmen kann. Projektmanager haben somit ein Frühwarnsystem an der Hand, das wirkungsvolles Risiko-Management in Entwicklungs- und Wartungsprojekten überhaupt erst möglich macht. Denn nur wer weiß, wo die Eisberge tatsächlich liegen, kann auch rechtzeitig reagieren und sie sicher umschiffen. Marc Hildebrandt __________________________________________ Marc Hildebrandt, Geschäftsführer, Software Diagnostics GmbH
Abbildung 1: Code Quality Map Die Code Quality Map deckt Qualitätsschwachstellen im Code und somit Risiken für die Weiterentwicklung und Wartbarkeit des Systems auf. (Jboss von Redhat, betrachteter Zeitraum September 2010-Januar 2011, Quelle: Software Diagnostics)
Abbildung 2: Team Performance Map Mit der Team Performance Map lassen sich Code-Dateien identifizieren, die unnötige Kosten verursachen. (Jboss von Redhat, betrachteter Zeitraum April 2010-Januar 2011, Quelle: Software Diagnostics)
Abbildung 3: Bug fix Map Codedateien, die oft im Kontext von Bugfixes korrigiert werden mussten, stellen ein strukturelles Problem für zukünftige Entwicklungen und Anpassungen der Implementierung dar. (Jboss von Redhat, betrachteter Zeitraum September 2010-Januar 2011, Quelle: Software Diagnostics)
|
