-
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 bezüglich
dieser Änderung
involviert waren
CIF = n·c·d
-
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 Änderungsauswirkungsfaktor
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-L1, ... CIFL4 aufweist,
wobei die Ebene CIF-L1 das gesamte Softwarepaket SP, die Ebene CIF-L2
unmittelbar darunterliegende Komponenten C1 und C2, die Ebene CIF-L3
Subkomponenten SC1 und SC2 und die unterste Ebene CIF-L4 Module
M11, .. 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 Änderungsauswirkungsfaktor
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:
| Zeile | Database | ID | n | C | d | cross-impact-factor |
| 1 | Package/Baseline | Summary | 24 | 8 | 23 | 4415 |
| 2 | Bugzilla | Summary | 20 | 5 | 18 | 1800 |
| 3 | DJ9266 | 4 | 3 | 3 | 36 |
| 4 | DJ9977 | 4 | 1 | 4 | 16 |
| 5 | DK1933 | 2 | 2 | 2 | 8 |
| 6 | DI2667 | 3 | 2 | 1 | 6 |
| 7 | DK0537 | 2 | 1 | 2 | 4 |
| 8 | DJ607 | 2 | 1 | 1 | 2 |
| 9 | DK0163 | 2 | 1 | 1 | 2 |
| 10 | DJ9683 | 1 | 1 | 1 | 2 |
| 11 | DJ8766 | 1 | 1 | 2 | 2 |
| 12 | DJ5317 | 1 | 1 | 1 | 1 |
| 13 | DJ8052 | 1 | 1 | 1 | 1 |
| 14 | DJ5337 | 1 | 1 | 1 | 1 |
| 15 | Clear Quest | Summary | 5 | 2 | 2 | 20 |
| 16 | LM50240 | 3 | 1 | 1 | 3 |
| 17 | LM50243 | 1 | 1 | 1 | 1 |
| 18 | LM24050 | 1 | 1 | 1 | 1 |
| 19 | Feature-DB | Summary | 8 | 4 | 5 | 200 |
| 20 | FT76434 | 3 | 2 | 3 | 18 |
| 21 | FT23543 | 5 | 1 | 1 | 5 |
| 22 | FT65273 | 3 | 1 | 1 | 3 |
| 23 | FT87454 | 1 | 1 | 1 | 1 |
| 24 | FT23653 | 1 | 1 | 1 | 1 |
-
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.