Validierungsprozess

Im Validierungsprozess werden die internen und externen Validierungskriterien theoretisch und empirisch überprüft, um zu festzustellen, ob ein Maß tatsächlich eine homomorphe Abbildung der empirischen Objekte in die formalen Objekte darstellt. Abb. 2.9 auf der nächsten Seite veranschaulicht diesen Prozess in Bezug auf die Vermessung von Softwareprodukten (der Ablauf erfolgt in der Abbildung von unten nach oben).

Ein reales Softwareprodukt mit internen und externen Eigenschaften (in der Ab-bildung unten mittig) wird zunächst zum Zweck der Vermessung auf geeignete Weise modelliert (siehe Abschnitt 2.2, S. 28). Produktmaße erfassen nur die Ei-genschaften dieser modellhaften Messobjekte, etwa Kontrollflussgraphen. Welche Art nützlicher Aussagen über das Softwareprodukt aus Produktmaßen abgeleitet

werden können, hängt also von der Art und Güte der Modellierung des Produkts durch die Messobjekte ab. Kontrollflussgraphen etwa abstrahieren von der For-matierung des Programmtextes, von Kommentaren, Dokumentation und vielem mehr, das für die Qualität des Produkts von Bedeutung ist. Diese Einschränkun-gen müssen bei der Anwendung von Produktmaßen berücksichtigt werden, um keine unzulässigen Aussagen über Eigenschaften abzuleiten, die im Messobjekt nicht modelliert sind.

eigene Grafik

Abbildung 2.9– Objekte und Akteure, die den Validierungsprozess beeinflussen

Je nachdem, ob interne oder externe Eigenschaften gemessen werden sollen, wird ein anderes Messobjekt erstellt: für interne Eigenschaften wie die Anzahl von Aufrufbeziehungen zwischen Funktionen etwa der erwähnte Kontrollflussgraph, für externe Eigenschaften wie die Bearbeitungseffizienz von Fehlern beispielswei-se eine Sammlung von ·Fällen aus einem Fallbearbeitungssystem, die Fehler oder Schwachstellen des Softwareprodukts abbilden. Die Eigenschaften dieser Mess-objekte werden dann stellvertretend für die entsprechenden Eigenschaften des Softwareprodukts durch interne oder externe Maße gemessen, woraus interne und externe Messwerte resultieren (in der Abbildung ganz oben). Bei der verbreitetes-ten Form der Validierung, der externen empirischen Validierung interner Maße, wird dann statistisch untersucht, welche Zusammenhänge zwischen diesen Mess-werten bestehen. Unter der Voraussetzung, dass sowohl das interne als auch das

externe Maß intern valide sind, kann aus dem statistischen Zusammenhang auf die externe Validität des internen Maßes geschlossen werden, das heißt darauf, ob das interne Maß mit einer externen Eigenschaft zusammenhängt.

Es werden nun weitere Faktoren umrissen, die die Softwarequalität beeinflussen, gefolgt von einer Diskussion der Herausforderungen bei der Untersuchung von Softwarefehlern als Grundlage externer Eigenschaften.

2.3.4.1 Vielfältige Einflüsse auf die Softwarequalität

Die Qualität des Softwareprodukts wird von vielfältigen Faktoren beeinflusst ist, die in Softwaremaßen nur indirekt widergespiegelt werden. Diese Einflüsse sind in Abb. 2.9, S. 38 durch Pfeile mit dem Produkt und seinen Modellen verknüpft.

Sie zerfallen in drei Bereiche: Einflüsse seitens der Softwareentwickler, seitens der Benutzer und Einflüsse durch Hardware und andere Software.

Die Entwickler der Software nehmen offensichtlich starken Einfluss auf deren Qua-lität. Wie sich dieser Einfluss gestaltet, hängt unter anderem von der fachlichen Qualifikation, vom Motivationsgrad und der Leistungsfähigkeit während des Ent-wicklungsprozesses ab. Mangelhaft ausgebildete Entwickler produzieren vermut-lich Software niedrigerer Qualität als gut ausgebildete; höher motivierte Entwick-ler lassen möglicherweise größere Sorgfalt walten und produzieren so etwa weniger Fehler; Entwickler, die durch zu lange Arbeitszeiten oder andere Aufgaben stär-ker ausgelastet sind, erreichen beim untersuchten Produkt eher nicht ihre volle Produktivität. Zudem sind Entwickler auf Vorleistungen anderer Entwickler, wie Spezifikations- oder Entwurfsdokumente, angewiesen. Deren Qualität beeinflusst offenbar auch die Qualität des Endprodukts.

Die Betriebsumgebung des Softwareprodukts, die aus Hardware und anderer Soft-ware besteht, beeinflusst die Qualität, da das SoftSoft-wareprodukt bestimmte Eigen-schaften aufweisen muss, um mit der Umgebung interagieren zu können.

Auch die Benutzer üben einen Einfluss auf die Softwarequalität aus, indem sie durch Benutzung dessen Eigenschaften erleben und die Entwickler direkt oder indirekt zu Veränderungen am Produkt oder an zukünftigen Produkten anhalten.

Näheres dazu im nächsten Abschnitt.

Alle diese Faktoren wirken als Hintergrundvariablen auf die Softwarequalität ein.

Ziel der Validierung muss es daher sein, den Einfluss dieser Variablen bei der Be-wertung von Softwaremaßen zu berücksichtigen. Dies stößt auf erhebliche Schwie-rigkeiten, da es schon eine seltene Gelegenheit ist, wenn zu einem Untersuchungs-objekt sowohl Quellcode als auch umfassende Fehleraufzeichnungen für einen lan-gen Zeitraum verfügbar sind [44:2] – konkrete Informationen über Eilan-genschaften der Entwickler, Benutzer oder der Betriebsumgebung sind nur schwer zu erlangen.

2.3.4.2 Empirische Validierung in Bezug auf Softwarefehler

Da ein zentrales Anliegen bei der Softwareentwicklung die Vermeidung und ge-gebenfalls schnelle und effiziente Beseitigung von Softwarefehlern ist, werden bei empirischen Validierungsstudien meist externe Eigenschaften betrachtet, die mit Fehlern im Softwareprodukt verbunden sind.

Fehlerhafte Software, die zum Einsatz kommt, kann schädliche Auswirkungen ha-ben und so noch höheren Aufwand zur Behebung der entstandenen Schäden ver-ursachen, sei es der Absturz eines Flugzeugs wegen fehlerhafter Steuerungssoftwa-re oder Datenverlust auf Grund eines Fehlers beim Speichern eines Dokuments.

Softwarefehler müssen möglichst frühzeitig vermieden oder gegebenenfalls erkannt werden, weil der Aufwand für ihre Behebung mit fortschreitendem Entwicklungs-prozess exponentiell ansteigt.

Dabei wird zwischen Fehlerursache, Fehlerzustand und Fehlerauswirkung unter-schieden [83:333]. Die Fehlerursache liegt als Irrtum oder Störung außerhalb des Softwaresystems. Als Fehlerzustand bezeichnet man die interne Eigenschaft des Softwareprodukts, die unter Umständen zu fehlerhaftem Verhalten oder zum Aus-fall der Software, zur Fehlerauswirkung, führt. Diese Eigenschaft kann permanent statisch vorliegen oder sich dynamisch während der Ausführung einstellen. Im Fol-genden werden nur statische Fehlerzustände betrachtet, die kurz Fehler genannt werden. Nach Schlingloff [83:333] sind „Softwarefehler immer systematischer Na-tur und lassen sich auf Irrtümer bei der Konstruktion der Software zurückführen“.

Von verschiedenen Softwaremaßen wie der ·zyklomatischen Komplexität wird an-genommen, dass sie mit der Wahrscheinlichkeit solcher Irrtümer in Beziehung stehen.

Große Softwaresysteme enthalten wahrscheinlich immer mehr·Fehler, als auf Grund beobachteter ·Fehlerauswirkungen bekannt sind. Die bekannten Fehler sind al-so nur eine Teilmenge aller ·Fehler. Von den bekannten Fehlern wird wiederum nur eine Teilmenge in potentiellen Datenquellen empirischer Untersuchungen ver-merkt. Eine Art solcher Datenquellen sind ·Fallbearbeitungssysteme (siehe Ab-schnitt 2.2.4, S. 31).

Die Fälle in einem Fallbearbeitungssystem, die vom Typ Fehlersind (siehe Ab-schnitt 2.2.4, S. 31), repräsentieren eine Stichprobe aus allen bekannten Fehlern.

Diese Stichprobe ist zu einem bestimmten unbekannten Ausmaß fehlerhaft und verzerrt. Hooimeijer und Weimer [43:35] berichten etwa, dass zwischen 2003 und 2006 beim Mozilla-Projekt 140 Fehler-Fälle erstellt wurden, die sich auf den selben ·Fehler in einer Fortschrittsanzeige bezogen. Diese 140Fehlerwurden nur nach und nach als Duplikate erkannt und markiert, so dass zu jedem beliebigen Zeitpunkt dieser einzelne Fehler im Fallbearbeitungssystem deutlich überrepräsen-tiert war. Die Qualität und Relevanz derFehlerund anderer Fälle zu bestimmen, ist ein kompliziertes Problem für sich, das in empirischen Studien im Gebiet der Softwaretechnik jedoch selten angegangen wird [9:122].

Für die Untersuchung von Beziehungen zwischen internen Softwaremaßen und Fehlern müssen Fehler den betroffenen Programmkomponenten zugeordnet wer-den. Die Standardmethode, die auch in der vorliegenden Arbeit angewendet wird, ist laut Bird u. a. [9:125], die Einträge im Änderungsprotokoll von Versionsver-waltungssystemen wie CVS oder git nach den Bezeichnern von Fehlern zu durchsuchen und einer Programmkomponente diejenigenFehlerzuzuordnen, die in ihren Änderungseinträgen vermerkt sind. Mit dieser Methode können fast alle Fehler zugeordnet werden, die in Änderungseinträgen vermerkt sind [9:125]. Je-doch sind oft nur ein Viertel bis die Hälfte aller Fehler derart vermerkt. Laut Bird u. a. [9:129] ist es sehr aufwändig festzustellen, auf welche Weise diese Stich-probe der Fehler verzerrt ist – was es erlauben würde, Rückschlüsse auf die nicht verknüpften Fehler zu ziehen.

Da Fehler oft nur alsFehlerregistriert werden können, wenn es zu einer ·Fehler-auswirkung gekommen ist, hängt die Verteilung der Fehler auf die Programm-komponenten nicht nur von der Verteilung tatsächlicher ·Fehler ab, sondern auch von der Ausführungsdauer und -häufigkeit sowie der Größe der Komponenten und vom Meldeverhalten der Entwickler und Benutzer. Mit zunehmender Lebenszeit

oder Ausführungsdauer einer Komponente steigt die Wahrscheinlichkeit, dass vor-handene Fehler auftreten und auch gemeldet werden. Mit zunehmender Größe einer Komponente hingegen ist anzunehmen, dass die Auftretenswahrscheinlich-keit jedes einzelnen Fehlers sinkt, da die WahrscheinlichAuftretenswahrscheinlich-keit der Ausführung jedes entsprechenden Programmabschnitts tendenziell sinkt [57:247]. Eine selten ausge-führte Komponente voller Fehler kann so als völlig Fehler-frei erscheinen. Die Häufigkeitsverteilung der Nutzungsdauer und -intensität und daher auch deren Einfluss auf die Anzahl bekannter Fehler sind meist unbekannt [44:12]. Das für diese Arbeit entwickelte Verfahren zur Zuordnung von Fehlern und anderen

·Fällen zu Programmkomponenten wird in Abschnitt 4.2.3, S. 69 näher beschrie-ben.