Beschreibung

Verfahren zur quantitativen Beurteilung von änderungen in einem Software-System und deren Auswirkungen

Die Erfindung betrifft ein Verfahren zur quantitativen Beurteilung von änderungen in einem Software-System und deren Auswirkungen, bei dem eine Klassifizierung der änderungen erfolgt .

In einer Software Entwicklung gibt es sehr viele änderungen in sehr kurzen Zeiträumen. Eine Test-Abteilung hat nun zu entscheiden was intensiv, bzw. weniger intensiv getestet werden sollte. Vollständige Tests können meistens auf Grund von Zeitmangel nicht ausgeführt werden. Daher benötigt die Test-Abteilung klare Informationen welche Bereiche eines Software-Produkts intensiver getestet werden sollten. Das wird umso wichtiger wenn die Entwicklungsabteilung meldet das eine bestimmte Anzahl Fehler beseitigt worden sind und zu entscheiden ist welche Fehler-Beseitigungen nun zuerst und wie intensiv diese getestet werden sollen.

Nach dem derzeitigem Stand der Technik wird jedem Fehler ein sogenannter „Severity Level" zugewiesen, d.h. es wird auf Grund von qualitativen Aussagen von Software Architekten,

Kunden, oder Projekt Managern eine Aussage über die mögliche Schwere, bzw. damit auch über die Wichtigkeit des Fehler gemacht. Dieser Level sagt aber gar nichts über die möglichen Schwierigkeiten aus, die sich bei der Beseitigung des Fehlers ergeben. Schwerwiegende Fehler können und haben sogar meistens eine sehr einfache Ursache, einmal erkannt ist die Lösung aber sehr oft trivial bzw. sogenannte leichtgewichtige Fehler können hingegen eine komplexe Fehlerbeseitigung zur Folge haben. Mit jeder Fehlerbeseitigung, bzw. eigentlich mit jeglicher änderung in einem Software System besteht die Gefahr das unbeabsichtigt neue Fehler eingebaut werden.

Nach dem derzeitigen Stand der Technik wird versucht - meistens mehr schlecht als recht - die jeweilige Fehlerbeseitigung oder ähnliche änderungen mit Software Qualitäts-Methoden wie "pair debugging", "code -reviews" und "pair coding" zu verifizieren. Diese Methoden führen allerdings nur mit sehr großem Aufwand zu befriedigenden Resultaten. Vielfach sind diese Methoden aber aus Zeitgründen nicht vollständig durchführbar, was wiederum zur Folge hat, dass oft unbeabsichtigt neue Fehler in das System eingebaut werden.

Eine weitere änderungsklasse sind z.B. die Implementierungen von System Anforderungen. Hier liegt die Herausforderung möglichst frühzeitig zu erkennen welche - auch teilweise - implementierten System Anforderungen bedeuten das größte Risiko bezüglich Projekts Erfolg oder Miss-Erfolg.

Die der Anmeldung zu Grunde liegende Aufgabe liegt nun darin ein einfaches aber möglichstaussagefähiges Verfahren zur quantitativen Beurteilung von änderungen in einem Software- System und deren Auswirkungen anzugeben, bei dem die oben genannten ganz oder weitgehend vermieden werden.

Diese Aufgabe wird erfindungsgemäß durch die Merkmale des Anspruchs 1 gelöst. Die Merkmale der Unteransprüche betreffen vorteilhafte Ausgestaltungen der Erfindung sowie vorteilhafte Verwendungen.

Nachfolgend wird die Erfindung anhand eines in der Zeichnung dargestellten Ausführungsbeispiels näher erläutert.

Die Erfindung besteht im Wesentlichen darin, dass auf einfache und sehr zuverlässige Weise eine Klassifizierung aller änderungen nach dem Kriterium erfolgt, welchen Einfluss diese auf das System hatten. Es wird keine Information über die Projekt-Struktur, sondern nur eine sehr begrenzte Information über die Software-Architektur benötigt. Hierzu werden für die änderungen jeweilige änderungsauswirkungs-

faktoren (cross-impact-factors) berechnet und dann in einer bspw. nach der Größe fallenden Liste dargestellt. Damit bekommt eine Test-Abteilung sehr klare Hinweise in welcher Reihenfolge die Tests vorteilhafterweise durchgeführt werden sollen, wobei aber auch noch qualitative Aussagen, wie Severity Levels o. ä., mit berücksichtigt werden können. Die notwendigen Werte für die Formel können leicht aus den Daten des benutzten Konfiguration Management System extrahiert werden. Eine Vorbedingung ist das die IDs für die Fehler Kennzeichnung, "Feature" IDs und ähnliche IDs sich mittels jeweils eines regulären Ausdruckes definieren lassen.

Die Erfindung berechnet zu jeder änderung -die über eine ID identifizierbar ist - einen änderungsauswirkungsfaktor CIF (cross-impact-factor) und liefert dann für jeden ID-Typ eine Rangliste der jeweiligen änderungen sortiert nach fallenden CIF. D.h. es werden so viele Ranglisten berechnet wie es verschiedene ID-Typen gibt.

Eine änderung ist in diesem Zusammenhang entweder eine Fehlerbeseitigung, ein neues "Feature", oder irgendeine andere identifizierbare änderung.

Der berechnete änderungsauswirkungsfaktor CIF (cross-impact- factor) zeigt auf eine einfache numerische Weise den Einfluss ("Impact") der änderung auf das gesamte System an. Je höher (numerisch) der Faktor desto mehr Einfluss hatte die änderungen auf das Software System, daraus ergibt sich zwingend eine höhere Wahrscheinlichkeit bezüglich der Einführung von neuen Fehlern. Der änderungsauswirkungsfaktor CIF (cross-impact-factor) wird nach der folgenden Formel berechnet :

n = Anzahl der änderungen in denen dieselbe ID (Fehler-, Feature-ID, oder ähnliche) entdeckt wurden. c = Anzahl der verschiedenen Software Komponenten die bezüglich dieser änderung verändert wurden

d = Anzahl der verschiedenen Entwickler die be zügl ich dieser ände rung involviert waren

Damit wird eine Klassifizierung der Fehler-Beseitigungen nach ihrem tatsächlich Einfluss auf das Software System erreicht.

Ein weiteres Ausführungsbeispiel sieht vor noch weitere Einflussgrößen in die Formel mit aufzunehmen. Vorteilhaft sind Einflussgrößen, wie: s = Anzahl der verschiedenen Entwicklungsstandorte die an diese änderung mitgewirkt haben a = Anzahl der verschiedenen Entwicklungsabteilungen die an dieser änderung mitgewirkt haben.

In einem Verwendungsbeispiel wird nicht der

änderungsauswirkungsfaktor CIF für jede Anforderungs-ID zu einem bestimmten Zeitpunkt, sondern die Veränderung des cross-impact-factors CIF für jede Anforderungs-ID über die Zeit integriert bzw. summiert betrachtet. Zeigt die Integration des cross-impact-factors CIF für eine spezifische Anforderungs-ID, z.B. monoton steigende Werte, so wird dies erfindungsgemäß als ein Indiz für eine besonders risikoreiche Anforderung gewertet. Wenn für eine Anforderung die entsprechenden Implementierungen immer einen relativ großen Einfluss haben, ist die Gefahr gegeben, das erstens neue Fehler in das System eingebaut werden und zweitens die Anforderung eventuell noch einmal analysiert werden sollte, z. B. in Bezug auf technische Eindeutigkeit, d.h. ob diese Anforderung so definiert ist, dass die Umsetzung in eine Implementierung wirklich erfolgen kann, und in Bezug auf ihre wirkliche Notwendigkeit.

Sind alle änderungen klassifiziert nach ihrem Einfluss dann können die üblicherweise limitierten Test-Ressourcen erheblich zielgerichteter eingesetzt werden. Bei Fehler- Beseitigungen mit einem hohen änderungsauswirkungsfaktor CIF

(cross-impact-factor) soll der Test-Aufwand vorteilhafterweise umfangreicher sein, d.h. es soll nicht nur die Beseitigung des eigentlichen Fehlers berücksichtigt werden, sondern es soll so getestet werden das mögliche Seiteneffekte erkannt werden können. Wiederum bei Fehler- Beseitigungen mit einem sehr niedrigen änderungsauswirkungs- faktor CIF (cross-impact-factor) kann sich der Test Aufwand auf das Szenario des Fehlers beschränken und braucht nicht weiter ausgedehnt zu werden. Damit wird eine dem "Impact" der änderung angemessener Test Aufwand erreicht und das genau passend auf die jeweilige änderung im Software System.

In der Zeichnung ist beispielhaft die Struktur eines Software-Paketes dargestellt, wobei das Softwarepaket Ebenen CIF-Ll, ... CIFL4 aufweist, wobei die Ebene CIF-Ll das gesamte Softwarepaket SP, die Ebene CIF-L2 unmittelbar darunterliegende Komponenten Cl und C2, die Ebene CIF-L3 Subkomponenten SCl und SC2 und die unterste Ebene CIF-L4 Module MIl,.. M23 beinhaltet. Der änderungsauswirkungsfaktor CIF (cross-impact-factor) wird entlang der Software Architektur, also typischerweise auf allen Ebenen, für jede dieser Komponenten und für das gesamte Software Paket berechnet .

Diese Berechnungen werden mit jeder neuen sogenannten Baseline berechnet. Als eine Baseline ist hier in diesem Zusammenhang gemeint die Liste aller notwendigen Artefakte mit ihren Versionen für ein Software System zu einem bestimmten Zeitpunkt. Eine Baseline wird üblicherweise von einem Konfigurationsmanagement berechnet und der Entwicklungsabteilung zur Verfügung gestellt.

Die Frequenz der Berechnung, bzw. wann gibt es eine neue

Baseline gibt ist stark abhängig von der Entwicklungskultur und auch der Phase in der sich die Produkt Entwicklung befindet und bedeutet bspw. täglich oder wöchentlich.

Mit Hilfe dieser berechneten änderungsauswirkungsfaktor CIF Ranglisten ergibt sich eine sehr fein abgestufte aber auch

gleichzeitig sehr übersichtliche Darstellung welche änderung welchen Einfluss in der Software hatte. Für jede eindeutig definierbare ID, wie Fehlerbeseitigungs-ID, "Feature"-ID, oder ähnliches wird ein eigener CIF berechnet, der aber dann auch wieder in einem globalen änderungsauswirkungsfaktor CIF, der alle IDs mit einschließt wieder zusammengeführt wird. Damit ist es möglich je nach dem Reife-Zustand der Produktentwicklung entweder auf spezielle IDs mit deren änderungsauswirkungsfaktor CIF sich zu konzentrieren, oder aber mehr den globalen änderungsauswirkungsfaktor CIF zu beobachten .

Weiter stehen für jeden berechneten änderungsauswirkungs- faktor CIF die Eingangsdaten, d.h. die Namen der Komponenten, und die Namen Entwickler für eventuelle genauere Analysen zur Verfügung. All diese Informationen werden vollautomatisch aus den Daten die üblicherweise ein Konfigurations-Management- System zur Verfügung stellt berechnet. Die einzige Vorbedingung ist das jeder Entwickler die änderungen die mit einer ID, also einem zusätzlichen Leistungsmerkmal (Feature) , Fehler, oder ähnliches, zusammenhängen mit Hilfe des Konfigurations-Management-Systems an notiert hat.

Eine änderung bedeutet in diesem Zusammenhang nicht jede Datei die zu einer Fehlerbeseitigung verändert wurde, sondern eine änderung kann eine, oder aber auch mehrere Dateien enthalten. Egal wie viele Dateien für eine änderung von einem Entwickler notwendig sind, diese änderung wird als eine singuläre Aktion betrachtet, was durch den Parameter n in der Formel zum Ausdruck kommt.

Beispielhaft ist in der folgenden Tabelle ein Ausschnitt aus einer typischen „Entwicklungs-Baseline" von CIF Ranglisten zu sehen :

Die Tabelle zeigt die jeweiligen änderungsauswirkungsfaktoren von drei verschiedenen IDs „Bugzilla", „ClearQuest" und der „Feature-DB" an. Zusätzlich wird auch der globale änderungsauswirkungsfaktor CIF (cross-impact-factor) in Zeile 1 dargestellt. Die Zahlen in den "Summary" Zeilen sind keine einfachen mathematischen Summen von den Werten unterhalb. Diese Zahlen stellen die Anzahl der unterschiedlichen "änderungen", "Anzahl der Entwickler" und "Anzahl der Komponenten" die im Rahmen dieser Datenbank erfasst wurden. Es ist sehr leicht zu sehen das in dem o.a. Beispiel der Schwerpunkt der änderungen sich auf die IDs die in der „Bugzilla"-Datenbank erfasst wurden beziehen. Weiter ist auch

eindeutig zu sehen dass die IDs in den Zeilen 3 bis 6 die mit Abstand höchsten änderungsauswirkungsfaktoren aufweisen. Was dem Test-Team eindeutige Hinweise bezüglich der durchzuführenden Testumfänge gibt.