Rational Insight

Business Intelligence - auch für die IT

19.02.2013
Von Christian Stahn

Konzeptionelle Vorarbeit

Wie bei allen BI-Projekten muss man sich vor Beginn der technischen Umsetzung intensiv mit den Anforderungen auseinandersetzen und die entsprechende konzeptionelle Vorarbeit leisten, um sicherzustellen, dass wirklich nur die relevanten Informationen aus den Quellsystemen in das Datenmodell integriert werden. Ausgangspunkt auf dem Weg zu den Kennzahlen und den zugehörigen Dimensionen sollten analog zu dem von Ralph Kimball vorgeschlagenen Vorgehen die zu steuernden Prozesse und die dabei jeweils verfolgten Ziele sein.

Aus Sicht des Anforderungs-Managements wäre dies etwa eine möglichst geringe Änderungsrate der in den nächsten Entwicklungszyklen umzusetzenden Requirements.

Ein Ziel des Release-Managements wäre beispielsweise, in einem neuen Release die Stabilität der bereits implementierten Funktionen sicherzustellen.

Als Ziel des Defect-Managements lässt sich wiederum die schnelle Bearbeitung und Behebung der gefundenen Fehler formulieren.

Erste Kennzahlen

Somit wären als erste Kennzahlen bereits die Zahl bestehender, neuer und geänderter Anforderungen, die Fehlerzahl in den Regressionstests sowie die Zahl und Bearbeitungszeiten von Defects identifiziert. Anschließend sind die gefundenen Kennzahlen auf die sie charakterisierenden Attribute hin zu analysieren, um daraus auf die Dimensionen zu schließen. Neben der "obligatorischen" Zeitdimension wären dies im ALM insbesondere die Releases oder Entwicklungszyklen und die Komponenten oder fachlichen Bereiche der Software. Relevante Filterkriterien für Anforderungen und Defects sind insbesondere Klassifizierungen nach Priorität, Kritikalität oder Risikoklasse.

Beim Aufbau des Datenmodells sollte man dabei dem Prinzip der "shared dimensions" folgen, nach dem identische Dimensionen, die für mehrere Kennzahlen relevant sind, für diese Metriken "wiederverwendet" werden. Auf diese Art lassen sich die Metriken der Data Marts einzelner Teildomänen miteinander vernetzen, so dass domänenübergreifende Auswertungen zur Analyse von Kausalzusammenhängen möglich werden.

Ein Praxisbeispiel wäre die Ursachen-analyse eines sprunghaften Anstiegs der in der Testphase eines Release gefundenen Defects. Möglicherweise ist dies auf eine besonders hohe Änderungsrate von bestehendem Code in der vorhergehenden Entwicklungsphase zurückzuführen? Oder ist die hohe Fehlerrate durch viele Changes an den Anforderungen der Iteration begründet? Ein entsprechendes Datenmodell erlaubt es, Zusammenhänge zu identifizieren, mit denen sich die Fragen beantworten lassen.