Seminar Methoden der empirischen Softwaretechnik

Transcrição

Seminar Methoden der empirischen
Softwaretechnik
Technischer Bericht 2006-3
Univ. Prof. Dr.-Ing. Stefan Kowalewski
Lehrstuhl Informatik XI
Betreuer: Dirk Wilking
RWTH Aachen
Wintersemester 05/06
c
Lehrstuhl
Informatik XI, RWTH Aachen University
Contents
Grundlagen
3
Enke
Empirische Forschungsmethoden . . . . . . . . . . . . . . . . . . . . .
5
Sanjaya
Experimententwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cai
Qualitative Measurement
. . . . . . . . . . . . . . . . . . . . . . . . . 55
Becher
Hypothesen und T-Test . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Wehlmann
Mehrfaktorielle Versuchspläne und Messwiederholungen . . . . . . . . . 101
Toborg
Kritik in der Statistik . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Experimente: Allgemein
146
Püttmann
The 28:1 Grant/Sackman legend . . . . . . . . . . . . . . . . . . . . . 149
Mattar
Die Annahme der statistischen Unabhängigkeit bei Multiversionsprogrammierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Briem
Untersuchungen zur Fehleranalyse . . . . . . . . . . . . . . . . . . . . . 189
Sonaimuthu
Documentation and Source Code Reading . . . . . . . . . . . . . . . . 213
Franken
Softwaremetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Experimente: Objektorientierung
Bai
Objektorientierte Entwürfe
260
. . . . . . . . . . . . . . . . . . . . . . . . 263
Yin
Experimente auf Designebene . . . . . . . . . . . . . . . . . . . . . . . 283
Experimente: Agile Methoden
302
Mahnkopf
Effekte des Pair Programming . . . . . . . . . . . . . . . . . . . . . . . 305
Ritzkopf
Effects of Test Driven Development . . . . . . . . . . . . . . . . . . . . 325
Grundlagen
Empirische Forschungsmethoden
Lutz Enke
Keywords: Empirie, Evaluation, Stochastik
Grundlagen
1
1.1
Einleitung
Was eigentlich ist Empirie?
Die Empirie (griechisch embiria – die Erfahrung) ist nichts anderes als auf
wissenschaftlichem, methodischen Wege gewonnene Erfahrung.
Kapitel 2 widmet sich, aufbauend auf einem historischen Rückblick und
einem Vergleich mit anderen wissenschaftlichen Methoden in Kapitel 1, den
eigentlichen Empirischen Forschungsmethoden, ihren Definitionen und ihrer
Anwendung auf die Naturwissenschaften.
In der Geschichte der Philosophie ordnet sich der Empirismus, der geisteswissenschaftlicher Vorreiter der sozial- und naturwissenschaftlichen Empirie zusammen mit dem Rationalismus auf der optimistischen Seite der
grundlegenden Frage ein, ob Erkenntnis erreichbar sei.
Dem gegenüber stehen die pessimistischen Theorien wie der des Skeptizismus oder des Relativismus entgegen, die Möglichkeit des Erreichens objektiver Erkenntnis aus grundsätzlichen Überlegungen heraus verneinen. Der
Konflikt zwischen Empirikern und Rationalisten einerseits mit Vertretern des
erkenntnistheoretisch pessimistischen Lagers wie David Hume andererseits
wird in 1.2 behandelt.
Wissenschaftstheoretisch steht der Empirie als naturwissenschaftlicher
Ansatz der Hermeneutik (sinngemäß Lehre vom Verstehen eines Textes“)
”
entgegen, dieser Konflikt wird in 1.4 behandelt.
1.2
Wo die Analytik versagt – oder: Wieso Empirie in der
Informatik?
Gerade im Bereich der Informatik läuft, ähnlich der Mathematik, ein großer
Teil der wissenschaftlichen und praktischen Arbeit auf rein analytischer
Ebene ab.
Die Frage, ob ein Programm terminiert ist ebenso mit reiner Logik beantwortbar wie die Frage nach der Beweisbarkeit eines mathematischen Satzes.
Der Informatiker könnte sich also mit gutem Gewissen als Analytiker bezeichnen, der a priori auf erkenntnistheoretische Spielereien wie der Empirie
verzichten könnte – schließlich ist sowohl die theoretische Vorarbeit der algorithmischen Problemlösung wie auch ihre Umsetzung auf Rechnersystemen
eine wohl definierte Umgebung, die theoretisch wie praktisch deterministisch
verläuft.
Doch ist die Informatik keine rein theoretische Wissenschaft, in der Realität und im Alltag muss sie sich vielfältigen Begrenzungen wirtschaftlicher
oder technischer Natur unterwerfen.
6
Methoden der empirischen Softwaretechnik
1 Einleitung
Die Zeit und die Kosten, die die Entwicklung einer Problemlösung verbrauchen sind ebenso wichtig, wie die deterministische Problemlösung an
sich; jedes Projekt ist dem gleichen Prinzip unterworfen, wie alles, was eine
Bedeutung für die Realität eines oder mehrerer Menschen hat: Die Kosten/Nutzenrechnung.
Da sowohl Kosten als auch Nutzen keine axiomatisch aufgebauten oder
auch nur aufbaubaren Größen sind, hilft hier weder pure Logik oder andere
rein analytische Verfahren. An dieser Stelle hält die Empirie und ihr gesamter
theoretischer Überbau auch in der Informatik Einzug:
• Wie viele Mittel setzte ich wo und wann ein, um ein Problem zu lösen?
• Wie lege ich erlaubte Ungenauigkeiten fest?
• Welche Heuristiken wähle ich zur Vereinfachung und wieso?
• Wie viel Zeit und Geld investiere ich, wie viel Personal setze ich ein,
um eine Lösung zu optimieren?
• Wann teile ich ein Projekt auf, und wie partitioniere ich es am besten?
All diese Fragen verlangen nach einer Antwort, die ihnen die Empirie im Rahmen ihrer Möglichkeiten (ihrer inhärenten und unausweichlichen, aber minimier- und steuerbaren Ungenauigkeit) geben kann.
Manche Fragen setzen Erfahrung heraus, manche Experimente. Manche
dieser Erfahrungen macht jeder Mensch in seinem Leben, viele jedoch
müssen auf wissenschaftlichem Wege gewonnen werden. Mittels empirischer
Forschungsmethoden.
1.3
Die Geschichte des wissenschaftlichen Experimentes
Auch wenn sich vereinzelt die Anfänge des Experimentes bei den griechischionischen Philosophen in Kleinasien finden lassen, ist der Durchbruch des
Experimentes als Form wissenschaftlicher Erkenntnis – und damit der Empirie – mit der Renaissance anzusetzen.
Seit dieser Zeit, genauer gesagt seit Francis Bacons Schrift Novum Organum setzte eine wahre Flut von Experimenten ein, deren erkenntnistheoretischer Wert erst durch einen Streit zwischen den Denkern Hume und Kant
in ein anderes Licht gerückt wurde.
Francis Bacon, dessen Namensvetter, der Franziskanermönch Roger Bacon, bereits im 13. Jahrhundert eine scientia experimentalis gefordert hatte,
postulierte sogar die Anwendbarkeit seiner experimentellen Methode auf
7
Grundlagen
alle Wissenschaften. Zwar machte schon die Scholastik, wie vor ihr andere
Philosophien Gebrauch von der beim Experiment grundlegenden Vorstellung
der Kausalitiät, an der Alleinursache aller kausalen Phänomene, nämlich
Gott, wurde nicht gerüttelt. Alles aber, was in Bewegung ist, wird von
”
einem anderen bewegt“ – Thomas von Aquin, Summa Theologica). Letzte
Ursache war immer Gott.
1.4
Hume und Kant – verschiedene Meinungen zur
Erkenntnistheorie
Die Wende von einer Metaphysik im ontologischen Gewand zur Empirie
wurde im englischen Empirismus vollzogen.
Kausalität wurde von David Hume (1711 – 1776, s. Abb.) nicht mehr deterministisch verstanden, sondern nur noch als gewohnheitsmäßige Verknüp”
fung im Denken“. Gleichzeitig verschiebt sich der Primat eindeutig auf die
Sinne, die allein den Schiedsrichter bei der Frage nach Ursache und Wirkung
spielen. Hume baut hierbei auf John Locke auf, der schon vorher behauptete,
dass sich alle Erkenntnis nur auf Erfahrung gründen könne.
Für Hume stellt sich die Kausalität als eine gewohnheitsmäßige Verknüp”
fung im Denken oder in der Einbildung zwischen einem Gegenstand und
seinem üblichen Begleiter“ (David Hume, An enquiry concerning human understanding) dar. Man kann Kausalität nämlich nie beweisen, sondern immer
nur einen mehr oder weniger großen Grad an connexion“ (Hume) zwischen
”
verschiedenen Phänomenen beobachten.
Humes wissenschaftlicher Kontrahent in dieser Betrachtungsweise war
der Königsberger Philosoph Immanuel Kant (1727 – 1804, s. Abb.). Kant
schloss, dass, wenn sich Kausalität nie beweisen ließe, der Begriff der Kausalität eine Vorstellung in unserem Denken sei, der über die reine Erfahrung
hinausginge.
Nach Kant kommt Erkenntnis erst dadurch zustande, dass unsere Sinneseindrücke nach einem Prinzip zu ordnen sind, das als notwendig gedacht
und postuliert werden muss. Er zog den Schluss, dass Kausalität etwas sein
müsse, was der Erfahrung vorausgeht, um die Erscheinungen der Wirklichkeit
überhaupt erklären zu können.
In Kants Terminologie: Kausalität ist ein Urteil a priori“.
”
Als Beweis dienten ihm die Sätze der Mathematik und der Geometrie,
die, obwohl unabhängig von Sinneseindrücken gefunden (Mathematik beruht
nur auf Axiomen und Logik), in der Wirklichkeit Gültigkeit hatten.
Im Kontrast zu Hume leugnete diese Sichtweise, dass menschliche Erkenntnis mit Sinneseindrücken allein möglich sei.
8
1 Einleitung
Im zwanzigsten Jahrhundert wiederholte sich dieser Streit in leicht veränderter Form.
Karl Popper (1902 – 1994) zog seit den dreißiger Jahren gegen die Neo”
Positivisten“ zu Felde, indem er den Primat der Theorie bei der Gewinnung
von Erkenntnissen betont. Ausschließlich bestimmte Annahmen von vornherein würden die Entscheidung zwischen unterschiedlichen Sinnesdaten ermöglichen, niemals jedoch die Sinne allein.
Erst theoretische Annahmen erlaubten es, die ungeordneten Daten der
Erfahrung aufzuschlüsseln und nach Ursache und Wirkung Ausschau zu halten.
Gilt einerseits in Fortführung der Gedanken Humes Kausalität nur als
probabilistische Beziehung1 , so wird andererseits die Behauptung Kants weitgehend geteilt, eine Ordnung und Erklärung der Sinnesdaten – also allem,
was ein Mensch im Experiment und damit der Empirie gewinnen kann –
wäre immer nur durch Rückgriff auf theoretische Sätze möglich, die vor der
Erhebung und Auswertung der Sinnesdaten aufzustellen sind
Die hier angeschnittene Diskussion, die zeigt, dass die Empirie auch
in der Moderne nicht unumstritten ist, lässt sich knapp zusammenfassen:
Die Kausalvorstellung ist nicht Ergebnis, sondern Voraussetzung em”
pirischer Erkenntnis“. Der Begriff der Kausalität dient damit als heuristisches Werkzeug, das beim Aufschlüsseln der Sinnesdaten nach Ursache und
Wirkung Hilfestellung leistet.
1.5
Hermeneutik – der große Widersacher?
Die Hermeneutik leitet sich linguistisch von Hermes, dem altgriechischen Götterboten ab, der den Menschen den Willen der Götter stets verschlüsselt,
und damit interpretationsanfällig, übermittelt hat; griechisch hermeneutike
techne – die Kunst des Interpretierens, Übersetzens, Erklärens und Auslegens.
Bezogen auf die Informatik findet die Hermeneutik nur im alltäglichsten
Sinne Anwendung, d.h. im Rahmen der menschlichen Interaktion und Kommunikation, beispielsweise wenn die vagen Anforderungen eines Projektes
in ein Pflichtenheft umformuliert werden oder Mitarbeiter die Memos ihrer
Kollegen entziffern müssen.
Nicht anwendbar ist sie jedoch in den Teilen der Informatik, die ihr wirklich als Wissenschaft zugeordnet werden können. Augenfällig ist dank der
1
Auch eine Variablenbeziehung mit einer Wahrscheinlichkeit von 0,999. . . , die de facto
gleich 1 wäre, ist nach der modernen Wissenschaftstheorie“ Poppers höchstens probabilis”
tischer und vorläufiger“ Art.
”
9
Grundlagen
syntaktischen Ähnlichkeit der Aufgabe das Interpretieren von Texten“, was
”
im informatischen Sinne die Aufgabe eines Compilers ist. Ein Compiler muss
per Definition deterministisch ablaufen, als Modell für ihn werden deterministische Automaten herangezogen. Das steht der Arbeitsweise und dem Selbstverständnis der Hermeneutik diametral entgegen.
Hauptproblem der Hermeneutik aus Sicht der Naturwissenschaften ist die
ungeklärte Frage nach der Validität (oder Glaubwürdigkeit) von ihr getroffener Aussagen.
Einziger Lichtblick scheint eine von C.S. Pierce (1839-1914) definierte
Schnittstelle zur Logik zu sein: Er interpretiert hermeneutische Aussagen
zunächst als Hypothesen bzw. abduktive Aussagen, sozusagen als Lückenfüller in unvollständigen logischen Systemen.
Diese Hypothese wird als zusätzliche Regel so gewählt, dass sie überraschende Phänomene als sinnvoller Fall dieser Regel gelten könnten.
Da ein unvollständiges logisches System durchaus zum Alltag
naturwissenschaftlicher oder informatischer Probleme gehören kann, ist sie
eine Möglichkeit, an Probleme heranzugehen, die auf den ersten Blick weder
mit Deduktion (Herleitung von Axiomen) oder Induktion (empirische Herleitung von vorhandenen Fakten) echt lösbar sind.
Ob es sich bei der Abduktion jedoch um einen echten logischen Schluss
handelt, ist umstritten – das gilt jedoch per se auch für die der Empirie
so eigene Induktion, da sie nur Wahrscheinlichkeitsaussagen als Schlussfolgerung von Stichproben treffen kann (s. Kapitel 2). Streng gesehen ist die
Hypothese zunächst kein Teil der Logik (jede neue echte“, aber bislang un”
bekannte Regel kann abduktiv gefolgerte Sätze über den Haufen werfen), sie
ist – wie der Hermeneutik so oft inne – eine Schnittstelle zwischen (oft von
Menschenhand) unzulänglich präzisen Daten oder Problembeschreibungen
und der Logik oder der Informatik.
Der Vollständigkeit halber sei erwähnt, dass natürlich gerade diese Funktion die Hermeneutik an anderer Stelle unverzichtbar macht, so basiert die
Rechtsprechung sogar in ihrer Selbstauffassung auf ihr (Rechtshermeneutik).
Gesetzestexte sind, im Gegensatz zu Gesetzen in den Naturwissenschaften,
der Interpretation ausgesetzt: Muss oder wird das Gericht sie wörtlich
nehmen, oder gibt es Spielraum für eine übertragene Anwendung?
Versöhnlicherweise stehen Empirie und Hermeneutik oft gar nicht in
direkter Konkurrenz, sondern sind eher Ausdruck verschiedener Herangehensweisen an ein Problem. So versucht sich die Medizin, dem Tod eines
Menschen empirisch zu nähern und ihn so ursächlich zu erklären. Die Geisteswissenschaften jedoch stellen eher eine Frage wie: Was ist der Tod¿‘.
”
Die Berechtigung einer solchen Frage im wissenschaftlichen Sinne kann
und soll hier nicht geklärt werden.
10
2 Empirische Forschungsmethoden
2
Empirische Forschungsmethoden
Empirische Forschungsmethoden sind Verfahren, mit denen Erfahrungswissen – also empirisch gewonnene Erkenntnisse – in systematischer und nachvollziehbarer Weise gewonnen und analysiert werden kann.
Ziele der empirischen Forschung sind:
1. Überprüfung von Theorien und daraus abgeleiteten Hypothesen
2. Untersuchung von singulären Sachverhalten
Einkommensverteilung eines Landes)
(z.B.
spezifische
3. Untersuchung von Wirkungen und Nebenwirkungen planerischer Maßnahmen (Wirkungs- oder Evaluationsforschung)
Eine grundlegende Unterscheidung empirischer Forschungsmethoden
kann in quantitative und qualitative Methoden erfolgen.
Wichtig bei der Wahl der Methode ist immer das zugrunde liegende
Erkenntnisinteresse. Qualitative Verfahren werden oft zur Erforschung eines
neuen Forschungsgebietes oder -gegenstandes benutzt und um Hypothesen
zu entwickeln. Quantitative Methoden setzen hingegen Hypothesen voraus,
die dann getestet werden. Oftmals folgt der explorativen Phase einer qualitativen Methode – die durchaus ergebnisoffen sein konnte – eine quantitative
Phase, in der entstandene Hypothesen empirisch überprüft werden.
2.1
Qualitative Methoden
Qualitative Methoden finden hauptsächlich Anwendung in der Sozialforschung und anderen auf den Menschen bezogenen Disziplinen. In den
Naturwissenschaften finden sie kaum Anwendung, ihre Datenerhebung erfolgt fast immer über Befragung oder Beobachtung von Menschen. Viele
solche sehen sich in hermeneutischer Tradition oder sind extrem spezifisch,
daher sei an dieser Stelle auf eine tiefer gehende Betrachtung dieser Methodenfamilie verzichtet.
2.2
Quantitative Methoden
Quantitative Methoden betreffen die Bereiche Datenerhebung, Messung,
Stichprobe und Datenanalyse. Durch Konsum- und Wahlforschung in den
Alltag eingerückt und unterfüttert durch mathematische Theorie ihrer Aussagekraft, sind sie das Herzstück wissenschaftlicher Empirie.
11
Grundlagen
Unterscheidungskriterien verschiedener quantitativer Methoden sind vor
allem die unterschiedlichen Methoden der Datenerhebung und die Anwendung statistischer und stochastischer Methoden wie Mittelwerte, Varianzen,
Stichprobengrößen oder Signfikanztests. In Abhängigkeit der Anzahl betrachteter Variablen unterscheidet man ein- oder mehrfaktorielle Untersuchungen; die Anzahl abhängiger Variablen teilt die Verfahren in univariate und
multivariate auf.
2.3
Datenerhebung
Sämtliche empirischen Forschungsmethoden setzen stets Datenbestände voraus. Von Interesse ist daher die Art der. Die häufigsten Verfahren hierfür
sind Befragung, Beobachtung und Experiment.
2.3.1
Befragung
Gängige Formen der Befragung sind
• mündliche Befragung
• schriftliche Befragung
• Telefoninterviews
• postalische Befragung
• computergestützte Selbstinterviews
Die Methode der Befragung hat ebenso einen Einfluss auf die Qualität der
Daten wie die Qualität der Fragestellungen und ihre Standardisierung. Meist
werden so genannte geschlossene Fragen gestellt, deren Antwortmöglichkeiten
fest vorgegeben sind, um die Vergleichbarkeit der Daten zu gewährleisten.
Bei gefragten Zahlenwerten (Zeitangaben, Mengenangaben etc.) spricht man
normalerweise auch bei freier Antwortmöglichkeit von geschlossenen Fragen,
da ihre Kategorisierung eine einfache Diskretisierung des zugrunde liegenden
Zahlenraumes ist.
2.3.2
Beobachtung
Unter Beobachtung versteht man das passive Verfolgen von Verhaltensweisen
oder Vorgängen unter Zuhilfenahme verschiedenster Aufzeichnungsarten. Im
Gegensatz zur Befragung kommt die Beobachtung bereits für die Überprüfung naturwissenschaftlicher Hypothesen in Frage.
12
3 Das Experiment
2.3.3
Experiment
Experiment meint die Gewinnung von Daten unter vollständig kontrollierten
Bedingungen. Das idealerweise nur bewusste Auftreten von Nebenbedingungen und störenden Faktoren kann hierbei die Relevanz des Datensatzes im
Vergleich zu unvollständiger Beobachtung stark erhöhen.
3
Das Experiment
3.1
Merkmale
Ein Experiment (lat. experimentum – Versuch, Beweis, Prüfung, Probe) im
wissenschaftlichen Sinne ist eine methodisch aufgebauter Versuch, der eine
Hypothese beweisen oder widerlegen soll.
Dazu werden unterschiedliche Situationen untersucht, in denen alle bis
auf einen Faktor der Kontrolle des Experimentes unterliegen, um ursächliche
Beziehungen zu diesem variablen Faktor zu zeigen. Der nicht kontrollierte
Faktor ist derjenige von besonders großem Interesse, da er die hypothetische
Wirkung oder Ursache darstellt. Als Beobachtung kann ein Experiment also
tatsächlich aufgefasst werden, jedoch ist die gängige Kurzdefinition: Ein
”
Experiment ist eine Beobachtung unter kontrollierten Bedingungen“ noch zu
unspezifisch, da sie nicht auf die Relevanz der zugrunde liegenden Hypothese
eingeht. Zur Gewinnung relevanter Daten gesellt sich die Notwendigkeit der
Wiederholbarkeit des Experimentes, welches jedoch je nach Auslegung bereits im Terminus Kontrolle“ enthalten ist. Selbstverständlich ist der Begriff
”
Kontrolle“ hier auch sehr relativ gesehen, denn gerade die Wiederholung
”
von Experimenten hat oft gezeigt, dass gleiche Versuchsanordnungen völlig
unterschiedliche Hypothesen zu bestätigen schienen. Zur Bewertung eines
Experimentes ist also auch das Wissen oder die Vermutung über den Grad
der tatsächlichen Kontrolle, die vorliegt, relevant.
Als Merkmale eines Experimentes seien hier deshalb festgehalten:
1. Hypothese
2. unterschiedliche Situationen
3. Kontrolle bis auf einen Faktor
4. Wiederholbarkeit (um Störfaktoren, die Punkt 3. entgehen, zu identifizieren)
Ein mögliches fünftes Kriterium, welches jedoch entweder trivial oder sehr
schwer zu erfüllen sein kann, wäre die sogenannte ökologische Validität“,
”
13
Grundlagen
also die Frage, inwieweit sich ein Experiment, welches so viele Faktoren kontrolliert, überhaupt auf nicht-experimentelle Situationen generalisiert werden kann. Diese Frage muss jedoch im Einzelfall beantwortet werden, im
Allgemeinen schränkt jedoch eine Verletzung dieser Generalisierbarkeit nur
die Hypothese und ihren Wirkungsbereich ein, und nicht die Gültigkeit des
gesamten Experimentes.
3.2
Experiment vs. Beobachtung
Die oben genannte Kurzdefinition des Experimentes als Beobachtung unter
”
kontrollierten Bedingungen“ ist nicht nur unpräzise, sondern droht die Trennung der Methoden zur Datenerhebung (s. 2.3) zu verwässern. Tatsächlich
scheint die Trennung nicht ganz schlüssig, ist Beobachtung doch auch im Experiment notwendig. Als empirische Methode unterliegt der Begriff Beobachtung jedoch dem Primat der Passivität, welche dem Experiment entgegensteht.
Auch wenn man davon ausgeht, dass kontrollierte Beobachtung Voraussetzung aller wissenschaftlicher Methoden sei, bleibt ein Unterschied:
Das Experiment behält tatsächlich die aktive Kontrolle über die Faktoren,
die Beobachtung unterliegt lediglich der Notwendigkeit, diese Faktoren
wahrzunehmen.
Der von einigen Sozialwissenschaftlern vertretene Ansicht, die Beobachtung sei das übergeordnete Mittel der Forschung“ als Folgerung daraus, dass
”
man ohne kontrollierte Beobachtung nicht auskomme, scheint also falsch,
denn dann könnte man ebenso gut der Statistik diese Rolle zugestehen.
Die reine Beobachtung als Datenerhebungsmethode über das Experiment zu
stellen hieße, das Handwerkszeug zum König zu machen.
3.3
Definition
Eine abgrenzende Definition des Begriffes scheint also zweckmäßig:
Experiment:
Wiederholbare Beobachtung unter kontrollierten Bedingungen, wobei
eine (oder mehrere) unabhängige Variable(n) derartig manipuliert wird
(werden), dass eine Überprüfungsmöglichkeit der zugrunde liegenden Hypothese (Behauptung eines Kausalzusammenhangs) in unterschiedlichen Situationen gegeben ist
14
3 Das Experiment
3.4
Mills Methoden
Für die Logik des Experiments ist das Buch von John Stuart Mill (18061883), A System of Logic so etwas wie ein veralteter Klassiker.
Klassiker“, weil einige seiner Regeln noch heute begrenzte Gültigkeit
”
haben, veraltet“, weil die Entwicklung der Logik und des Experimentes eine
”
Vielzahl von spezifizierenden Bedingungen zutage gefördert hat, an deren
Existenz zu Mills Zeiten nicht oder kaum zu denken war.
Mill nennt vier Möglichkeiten kausaler Aussagen beim Experiment. Ihre
teilweise Gültigkeit und das, was nach dem Stand der letzten 150 Jahre gegen
sie spricht, veranschaulicht Herangehensweisen und Trugschlüsse im Raum
der empirischen Forschung.
3.4.1
Methode der Übereinstimmung
Wenn zwei oder mehr Fälle der zu untersuchenden Erscheinung
”
nur einen Umstand gemeinsam haben, dann ist der Umstand, der
das alleinige übereinstimmende Merkmal sämtlicher Fälle ist, die
Ursache der betreffenden Erscheinung.“ (Mill, A System of Logic)
Das nachfolgende Beispiel zeigt jedoch sofort den Mangel dieser Methode:
A : T, U, V, W, X → Y
B : ¬T, ¬U, ¬V, ¬W, X → Y
Nach Mill wäre das gemeinsame Merkmal beider Fälle, X, die Ursache
für Y , also hinreichendes Merkmal (s. 4.1) für das Auftreten von Y . Dagegen
lassen sich aber folgende Einwände erheben:
1. Es ist nicht einzusehen, warum nicht irgendwelche anderen – u.U. für
A und B sogar verschiedenen – Merkmale, die hier nicht vertreten sind,
kausale Wirkung haben sollten.
2. Es wird sehr schwer sein, sich einen Fall zu denken, bei dem zwei Individuen nur ein Merkmal gemeinsam haben. Meistens bedeutet die Tatsache, dass ein Merkmal vorhanden ist, auch gleichzeitig das Vorhandensein anderer Merkmale. Hier sei nur an komplexe Phänomene wie
Gencode, soziale Schichtung oder Intelligenz erinnert.
3. Man kann keine Kausalaussage beweisen, also als absolut gesicherte
Erkenntnis bezeichnen (s. 4.1). Solche Aussagen wie hier müssen probabilistischen Charakter aufweisen.
15
Grundlagen
4. Der Geltungsbereich dieser Methode ist dadurch beschränkt, dass Mill
hier ausschließlich von zweiwertiger Logik ausgeht und damit die für die
Wissenschaft sehr relevante Quantifizierung von Merkmalsdimensionen
nicht berücksichtigte.
Betrachtet man die Methode als rein heuristisches Hilfsmittel zur Analyse möglicher Kausalitäten, mag sie in Verbindung mit anderen Techniken
durchaus ihre Berechtigung haben. So liefert sie bei vehementem Auftreten
doch oft Hinweise auf bedeutsame Variablen.
3.4.2
Methode der Differenz
Wenn ein Fall, in dem die untersuchte Erscheinung vorkommt,
”
und ein anderer, in dem sie nicht vorkommt, alle Umstände außer
einem gemeinsam haben, wobei dieser eine Umstand nur im erstgenannten Fall auftritt, dann ist der Umstand, durch den sich
die beiden unterscheiden, die Wirkung oder Ursache oder ein unentbehrlicher Teil der Ursache der Erscheinung.“ (Mill, A System
of Logic)
Die Logik dieser Methode lässt sich wie folgt veranschaulichen:
A : T, U, V, W, X → Y
B : T, U, V, W, ¬X → ¬Y
Hier würde man nach Mill schließen: X ist Ursache ( notwendiges Merk”
mal“, s. 4.2) für das Auftreten von Y , da im sonst gleichen Fall B X fehlt.
An dieser Methode ist folgendes zu kritisieren:
1. Wieder dürfte es schwer fallen, in der Wirklichkeit einen solchen Fall
zu finden, bei dem sich zwei Individuen nur in einem Merkmal unterscheiden, in allen anderen Merkmalen aber gleich sind.
Setzt man aber statt der Gleichheit in allen anderen Merkmalen nur
eine Zufallsstreuung voraus, die ihre verzerrenden Einflüsse gegenseitig
neutralisiert und damit intern validiert (s. 4.3), dann erscheint die
Leistungsfähigkeit dieser Methode in einem neuen Licht.
2. Der Fall ist denkbar, dass man zwar zwei Fälle wie oben tatsächlich
findet, aber nicht sagen kann, was Wirkung (= abhängige Variable)
und was Ursache (= unabhängige Variable) ist. Allerdings ist dieser
Einwand weitaus allgemeingültiger als nur diese Methode von Mills in
Frage zu stellen.
16
3 Das Experiment
Interpretiert man Mills Behauptung vom unentbehrlichen Teil der Ur”
sache der Erscheinung“ als probabilistisch, dann erweist sich die Methode der
Differenz als wesentlich brauchbarer für Kausalaussagen als die Methode der
Übereinstimmung. Lässt man dazu noch die anderen Faktoren nach dem Zufallsprinzip streuen, so kommt Mill hier schon nahe an eine der Kernmethoden
moderner Empirie heran: Die des sozialwissenschaftlichen Experiments.
3.4.3
Methode der gleichlautenden Variationen
Eine Erscheinung, die auf irgendeine Weise stets dann variiert,
”
wenn eine andere Erscheinung auf eine besondere Art und Weise
variiert, ist entweder eine Ursache oder eine Wirkung der betreffenden Erscheinung oder steht mit ihr durch irgendeine Kausalität
in Zusammenhang.“ (Mill, A System of Logic)
Bei dieser Methode geraten zum ersten Mal quantitative Hypothesen
(s. 2.2) in Mills Blickfeld. Es geht nicht mehr nur um Fragestellungen,
die nach den Auswirkungen eines Merkmals im Vergleich zur Nichtexistenz
dieses Merkmals fragen, sondern um Vergleiche stärkerer oder schwächerer
Beziehungen bei der Variation zweier Merkmale. Mill weist sogar in aller
Vorsicht darauf hin, dass es sich sowohl um Ursachen als auch um Wirkungen handeln kann, wird doch dieser Vorbehalt auch heute in der Praxis des
Öfteren noch übersehen.
Ob Mill mit seinem Nachsatz nur die Aussage des Vordersatzes schwächen
wollte, oder bereits an die Existenz weiterer Variablen gedacht hat, ist wohl
nicht entscheidbar. In jedem Fall gilt auch hier der Standardeinwand, dass
alles unter einem probabilistischen Deckmäntelchen gesehen werden muss.
Vergleicht man jeweils Merkmalspaare miteinander, dann ist die Methode der
gleichlaufenden Variationen eine Variante der Differenzmethode (s. 3.4.2).
3.4.4
Methode der Residuen
Wenn man von einer Erscheinung jenen Teil abzieht, von dem
”
man aus früheren Induktionen weiß, dass er die Wirkung bestimmter Voraussetzungen ist, dann ist der Rest des Phänomens
die Wirkung der noch verbleibenden Voraussetzungen.“ (Mill, A
System of Logic)
Hierbei handelt es sich um eine Methode, die auf einer anderen Ebene
liegt. Im Grunde geht es nämlich nur um die Anwendung einer Rechenregel.
Um einen derartigen Residualfaktor überhaupt zu vermuten, müsste man als
17
Grundlagen
Zeitgenosse Mills erst einmal von einer oder mehreren seiner anderen drei
Methoden Gebrauch machen.
Unter Mills vereinfachenden Annahmen ein Beispiel (entlehnt von E. Zimmermann): Vergliche man Studenten und Polizisten und wüsste, dass Studenten liberalere politische Ansichten hätte, sie im Schnitt mehr Bildung
genossen hätten und dazu auch noch überproportional aus Elternhäusern
der oberen Mittelschicht kämen, dann könnte man nach dieser vierten Methode vermuten, dass die restlichen Einflussgrößen für die Unterschiede der
politischen Einstellungen durch Subtraktion zu ermitteln wären, z.B. die
Möglichkeit, dass Studenten eher aus einer Großstadt kämen, Polizisten
hingegen eher vom Lande. Sichtbar wird, dass die vierte Methode aus
sich heraus nicht erklären“ kann. Bei der Erklärung des dritten Faktors,
”
Großstadt oder Land“, würde man im Rahmen der Millschen Analyse eine
”
abgeschwächte Form der Differenzmethode (3.4.2) anwenden.
Die moderne Analogie zur Methode der Residuen ist die Varianzanalyse, bei der auch versucht wird, bislang unerklärte Varianz in der oder den
abhängigen Variablen durch neue unabhängige Merkmale zu erklären.
M. R. Cohen und Ernest Nagel kommen in ihrem Werk An Introduction
to Logic and Scientific Method zu dem Schluss, dass die genannten Methoden
weder für eine Entdeckung der relevanten Variablen noch für Kausalnachweise
ausreichen. Bestenfalls ließen sich damit unzureichende Kausalbehauptungen
eliminieren. Als einfache und leicht nachvollziehbare Methoden – gerade auch
mit ihren Schwächen – sollen sie an dieser Stelle aber als Beispiele ausreichen.
4
Empirische Aussagen und ihre Qualität
Nachdem im Vorigen behandelt wurde, auf welche Weise man zu Datensätzen
gelangt und welche Folgerungen aus ihnen geschlossen werden könnten oder
sollten, fehlt noch jegliche Aussage darüber, unter welchen Bedingungen wir
einer getroffenen Aussage bzw. einer be- oder widerlegten Hypothese eine
gewisse Qualität und damit tatsächliche Aussagekraft zuordnen können.
Neben dem Prinzip von Ursache und Wirkung (Kausalität), dessen Nachweis überhaupt erst eine Bewertung der Ergebnisgüte erlaubt, gibt es weitere,
aufeinander aufbauende Gütekriterien für empirische Untersuchungen: Reliabilität, Validität und statistische Genauigkeit.
4.1
Kausalität
Für die Wertung einer empirischen Aussagen ist relevant, ob der für die
Belegung der Hypothese erforderliche Zusammenhang zwischen Ursache und
18
4 Empirische Aussagen und ihre Qualität
Wirkung überhaupt gegeben ist, oder ob es sich lediglich um eine zufällige
Korrelation o.ä. handelt.
Der Begriff Ursache teilt sich oft in die Begriffe Anlass, Bedingung und
Grund, wobei eine genaue Abgrenzung schwer fällt und auch strittig ist.
Einigkeit besteht meist über
• die Ursache als eine besondere Art der Bedingung (zeitlich vor der
Wirkung und wichtig für die Thematik),
• den Anlass als zufälligen (unwesentlichen) Auslöser einer Wirkung
neben der eigentlichen Ursache
• und den Begriff Grund als ideell im Gegensatz zum materialistischen
Begriff Ursache.
Weiterhin gilt, dass Kausalität empirisch nie total beweisbar ist. Streng
genommen ist Kausalität niemals zureichend beobachtbar. Zwischen der
theoretischen Sprache, in der man wie schon Kant die Kausalität als Hilfskonstruktion auffassen kann, und der empirischen Ebene klafft eine Lücke,
und sei sie im Fall naturwissenschaftlicher Gesetze, die millionenfach durch
Beobachtung verifiziert“ wurden, auch noch so klein.
”
An welchen Merkmalen ist also ein kausales Phänomen erkennbar?
Zwar liegt bei jeder Kausalbeziehung ein gemeinsames Auftreten zweier
Merkmale (= Korrelation) und eine zeitliche Abfolge vor, doch sind weder
Korrelation noch Folge allein ausreichend für eine Kausalaussage.
Das gemeinsame auftreten zweier Merkmale sagt noch nichts darüber aus,
was Ursache ist und was Wirkung, bzw. ob nicht dritte Variablen die Korrelation als Scheinkorrelation entlarven oder sie spezifizieren.
Folglich gilt der Satz: Jede Kausalaussage muss von (zwei oder mehr)
korrelierenden Phänomenen ausgehen (notwendige Bedingung), doch reicht
eine hohe Korrelation allein nicht aus für eine Kausalaussage.
Dasselbe trifft übrigens für eine Vorhersage zu. Diese kann zutreffend
sein, ohne dass das zugrunde liegende Gesetz bekannt ist ( Projektion“ im
”
Gegensatz zur Prognose“, die auf einer Gesetzesaussage beruht).
”
Ebenso gilt folgender Satz: Jede Kausalaussage muss eine zeitliche Abfolge beinhalten, doch reicht eine Folge allein nicht aus für eine Kausalaussage.
Beispiel: Zwar folgt der Tag auf die Nacht, doch verursacht die Nacht
nicht den Tag.
Der Fehlschluss von einem zeitlichen Ablauf auf einen ursächlichen wird
auch mit dem lateinischen Terminus post hoc ergo propter hoc“ bezeichnet.
”
19
Grundlagen
Entscheidend ist eben die Asymmetrie in der Variablenbeziehung und nicht
die zeitliche Abfolge.
Neben einem gemeinsamen Auftreten bzw. einer gemeinsamen Veränderung zweier Merkmale, auch Kovariation genannt, und einer zeitlichen Abfolge dieser beiden Phänomene müssen noch zwei weitere Bedingungen erfüllt
sein, wenn Kausalbeziehungen nachweisbar sein sollen. Zum einen muss es
sich um isolierte Systeme handeln, deren Variablen man – wie eben im Experiment – unter Kontrolle hat, zum anderen müssen alle möglichen Fehler
zufällig streuen, also nicht systematisch untereinander variieren.
Liegen also diese vier Bedingungen vor:
1. Korrelation von (zwei oder mehr) Merkmalen,
2. zeitliche Abfolge,
3. isoliertes System (= Kontrolle der relevanten Variablen) und
4. zufällige Streuung der Fehler,
dann kann man davon sprechen, dass z.B. ein X ein Y produziert, also
eine Asymmetrie in der Merkmalsbeziehung vorliegt. Allerdings kann diese
Asymmetrie auch wechselseitiger Natur sein, wenn man unterschiedliche Zeitpunkte betrachtet. So kann X im Zeitpunkt t0 Y hervorrufen, und Y im
Zeitpunkt t1 X veranlassen. Man spricht dann von reziproker Kausalität.
Ein Beispiel sei hierfür die Wechselwirkung von Sympathie und menschlicher
Interaktion.
Eine mehr wissenschaftstheoretische Frage ist, ob Kausalaussagen unbedingt deterministischen Charakter haben müssen. In der Realität erscheint
es zweckmäßiger, von wahrscheinlichkeitstheoretischen Aussagen auszugehen.
Man ist nämlich meist nicht in der Lage, alle vier oben aufgezählten Bedingungen genau zu erfüllen. Besonders die Kontrolle aller wichtigen Variablen
des Systems und die Forderung, dass die Fehler zufällig streuen müssen, bereiten Schwierigkeiten. Man kann von kausalen Beziehungen sprechen, wenn
die theoretische Struktur gegenüber zusätzlich eingeführten Variablen invariant bleibt.
Eine deterministische Aussage ist dann möglich, wenn – nochmals – die
obigen vier Kriterien erfüllt sind. Wenn man alle relevanten Variablen in
dem jeweiligen System kontrolliert hat, so bedeutet dies, X und nur X ist
die alleinige Ursache für das Auftreten von Y . Das heißt, immer dann, wenn
X auftritt oder eine Veränderung von X, dann folgt auch Y oder eine Veränderung von Y . Es besteht keine Möglichkeit, einer unabhängigen Variation
beider Merkmale.
20
Abschließend seien noch kurze Definitionen der hier relevanten Begriffe
von notwendiger“ und hinreichender“ Kausalität gegeben.
”
”
1. X ist eine notwendige und hinreichende Bedingung für Y : Beide Merkmale tauchen zusammen oder überhaupt nicht auf.
2. X ist eine notwendige, aber keine hinreichende Bedingung für Y : X
muss für die Beobachtung von Y vorhanden sein, doch nicht auf jedes
X folgt ein Y .
3. X ist eine hinreichende, aber keine notwendige Bedingung für Y : Y
liegt immer vor, wenn X vorliegt, doch kann Y auch unabhängig davon
auftreten.
4.2
Reliabilität
Reliabilität ist ein Maß für die formale Genauigkeit einer empirischen Untersuchung. Eine völlig reliable Untersuchung ist frei von Zufallsfehlern,
d.h. exakt gleiche Rahmenbedingungen würden bei Wiederholung des Experimentes/der Befragung gleiche Messergebnisse oder zumindest identische
Schlüsse zur Folge haben.
Die praktische Umsetzung dieses Anspruchs stößt schnell an ihre Grenzen: Insbesondere, wenn die Leistung von Menschen auf irgendeine Weise in
die Messung hineinfließt (Wahlverhalten, Arbeitsleistung, taktile Genauigkeit
beim Messen), müssen grundlegende Schwankungen als gegeben hingenommen werden und damit auch gemessen werden müsste. In der Regel begnügt
sich die Reliabilität daher auf Wiederholung unter vermeintlich gleichen Rahmenbedingungen, um ihr Gütesiegel zu vergeben.
4.3
Validität
Validität (lat. validus – stark, wirksam, gesund) bezeichnet das argumentative Gewicht einer Aussage oder Hypothese. Im Gegensatz zur Falsifizierund Verifizierbarkeit ist sie kein boolesches Kriterium, sondern ein kontinuierliches Maß für die Gültigkeit einer wissenschaftlichen Feststellung.
Sinnvoll ist eine Unterteilung in verschiedene Aspekte.
• Externe Validität
Auch Allgemeingültigkeit oder ökologische Validität. Bezeichnet die
Übereinstimmung zwischen tatsächlichem und beabsichtigtem Untersuchungsgegenstand, ergo: Wie generalisierbar sind die Erkenntnisse
eines Experimentes?
21
Grundlagen
• Interne Validität
Interne Validität misst die Fähigkeit eines Experimentes, mögliche
Störvariablen zu kontrollieren. Das bezieht sich beispielsweise auf die
Qualität eigentlich nicht untersuchter Daten wie beispielsweise soziale
Herkunft und Bildungsstand in der Wahlforschung, um auszuschließen,
dass durch einen Zufall diese Störvariablen schlecht verteilt sind.
• Konstruktvalidität
Bemisst die Fähigkeit des Experimentes, tatsächlich das gewünschte
Konstrukt zu messen. Diese Forderung bzw. Frage ergeht häufig an
Intelligenztests, bei denen die Gefahr besteht, dass zu einem Teil bloß
Gewandtheit innerhalb der gesellschaftlichen Konventionen, unter denen der Test entstanden ist, getestet wird. Gute Intelligenztests werben
daher mit Belegen für ihre Konstruktvalidität.
• Konvergente Validität
In wie weit korrelieren die Ergebnisse eines Experimentes/einer Umfrage mit denen ähnlicher Tests? Eine gute konvergente Validität ist
gewährleistet, wenn Ergebnisse eines neuen Tests mit bekannten Tests
hoch korrelieren.
• Diskriminante Validität
Ähnlich der konvergenten Validität werden hierbei die Ergebnisse des
zu validierenden Tests mit bisherigen Resultaten vergleichen. Hier
soll jedoch sichergestellt werden, dass bereits erfasste Merkmale nicht
nochmals gemessen werden.
Zwischenbemerkung: Ein Nachweis der Konstruktvalidität verlangt
Nachweise von sowohl konvergenter als auch diskriminanter Validität.
• Kriteriumsvalidität
Die Kriteriumsvalidität zielt auf den Zusammenhang zwischen empirisch gemessenen Ergebnissen des eigentlichen Messinstruments und
einem anders (extern) gemessenen empirischen Kriteriums ab. Sie wird
unterteilt in:
• Übereinstimmungsvalidität
Wird der Test zeitgleich mit einem anderen durchgeführt (Außenkriterium), und wird dieser ebenfalls überprüft, so kann von einer Übereinstimmungsvalidität gesprochen werden.
• Prognostische Validität
Prognostische Validität ist dann gegeben, wenn dem Test nachfolgende
22
Messungen (Außenkriterium) mittels der Ergebnisse des Tests prognostiziert werden können/konnten.
4.4
Statistische Genauigkeit
Der Grad der Kausalität, Reliabilität und Validität erlaubt Aussagen, wie gut
ein Experiment in der Lage ist, die Realität abzubilden und damit darüber, ob
seine Ergebnisse als Verifizierung oder Falsifizierung von Hypothesen geeignet
sind.
Die konkreten Ergebnisse eines Testes unterliegen jedoch, da im tatsächlich stattfindenden Experiment immer nur eine endliche Anzahl Situationen und damit Variablenbelegungen gemessen wird, dem Risiko der Ungenauigkeit.
Theoretisch gerät ein Wahlforscher in die Gefahr, obschon sein Modell
als sehr gut, seine Fragen als sinnvoll für die Wahlentscheidung (Kausalität),
seine Elimination von Störfaktoren als zuverlässig (Validität) und seine bisherigen Ergebnisse von hoher Güte (Reliabilität) waren, ein völlig falsches
Resultat zu prognostizieren.
Denn wer garantiert ihm, dass er trotz sorgfältiger Zufallsauswahl unter
Berücksichtigung einer Gleichverteilung der Befragten in puncto Wohnort,
Bildungsstand und familiärer Situation, nicht ausgerechnet tausend Wähler
der Bibeltreuen Christen befragt?
Theoretisch ist dies natürlich möglich, wenn auch sehr Unwahrscheinlich.
Deswegen spricht man nach – will man präzise sein – nach der Anwendung
empirischer Forschungsmethoden immer nur bedingt von bestimmten Ergebnissen. Üblich ist eine Formulierung wie zu 95% liegt die Abweichung des
”
realen Ergebnisses unter 5% vom Ergebnis der empirischen Erhebung/des
empirischen Experimentes“. Damit wäre gesagt, dass das Experiment bzw.
die Umfrage sowohl qualitativ als auch quantitativ gut genug waren, dass
die Wahrscheinlichkeit, ein mit 5% Fehlertoleranz gutes“ Ergebnis erzielt zu
”
haben, sehr hoch (95%) ist.
Derartige Qualitätsaussagen, die nach Garantierung von Validität und
Reliabilität des empirischen Experimentes getroffen werden können, sind völlig unabhängig vom Thema oder Untersuchungsgegenstand (eben im Gegensatz zur Validität und Reliabilität) und obliegen rein mathematischen Gesetzmäßigkeiten.
Elementarer Bestandteil der Datenauswertung zwischen Datenerhebung
(Experiment) und Präsentation (Bestätigung/Widerlegung der Hypothese)
ist daher sowohl die Hoch- als auch die Fehlerrechnung.
Während die Hochrechnung der experimentell gewonnenen Daten im
”
Wesentlichen“ mit der Grundgesamtheit übereinstimmen sollen und damit die
23
Grundlagen
Kernaussage der Präsentation darstellen, obliegt der Fehlerrechnung eben die
oben genannte Nennung von Ergebnisschwankungen und damit der Berechnung des Risikos, mit welchem das Treffen der gewünschten Aussage behaftet
ist.
References
[1] Zimmermann, E.: Das Experiment in der Sozialforschung, Teubner
[2] Mill, J. S.: A System of Logic
[3] Buhr, M; Klaus, G.: Philosophisches Wörterbuch, VEB Leipzig
[4] Schnell, R.; Hill, P.; Esser, E.: Methoden der empirischen Sozialforschung, Oldenbourg
[5] Nagel, E.; Cohen, M. R.: An Introduction to Logic and Scientific Method
[6] ILMES (http://home.att.net/~blackgr)
[7] Wikipedia (www.wikipedia.de)
24
Experimententwurf
Osmond Sanjaya Tedjasukmana
Grundlagen
1
Einführung
In der Softwaretechnik spricht man von ingenieurmäßigem Entwerfen, Herstellen und Implementieren einer Software. Innerhalb dieser Tätigkeiten kommen die folgenden bekannten Grundprobleme vor:
• Kosten der Softwareherstellung
Hier handelt es sich um die Einsparung der gesamten Arbeitkosten der
• Zykluszeit der Softwareherstellung
Unter der Zykluszeit versteht man die Gesamtdauer der Softwareherstellung.
• Verlässlichkeit der Software
Hier geht es um die Zahl und Art von Defekten in der Software.
• Brauchbarkeit der Software
Sie betrifft die Effizienz, Erlernbarkeit, Bedienbarkeit, etc.
Ein Beitrag zur Lösung der oben geschriebenen Grundprobleme soll an
ihrer Nützlichkeit gemessen werden, die in den meisten Fällen nur empirisch
nachgewiesen werden kann.
Der Begriff ”‘Empirie”’ stammt aus dem Griechischen ”‘empiria”’ und es
bedeutet Erfahrung. Es bezeichnet tatsächliche Ereignisse und Beobachtungen. Empirische Bewertung bedeutet praktische Verwendung und Erprobung
der Softwareartefakte (eines Werkzeuges, eines Modells oder einer Methode),
um deren Eigenschaften zu verstehen und beschreiben zu können.
1.1
Überblick der Empirische Forschungsmethoden in der
Softwaretechnik
Es gibt verschiedene empirische Forschungsmethoden und jede hat bestimmte
Eigenschaften, die bei der Auswahl der am meisten geeigeneten (günstigsten)
Forschungsmethoden nötig sind. Obwohl in dieser Ausarbeitung nur kontrollierte Experimente behandelt werden, werden einige andere empirische
Forschungsmethoden zum Vergleich kurz erläutert:
1. Fallstudie
Eine Fallstudie ist eine Studie der Softwareartefakte anhand eines
konkreten Anwendungsbeispiels, das speziell nur zu diesem Zweck unter
künstlichen oder typischen Bedingungen ausgeführt wird. Da der betrachtende Fall speziell nur einem Zweck dient, ist die Planung einfach,
aber es macht die Verallgemeinerung der Resultate schwierig. Eine
Fallstudie ist eine Beobachtungstudie.
26
1 Einführung
2. Feldstudie
Eine Feldstudie ist eine Studie der Softwareartefakte in einem realen
Softwareprojekt (”‘im Feld”’) und nicht in der Form eines Experiments. Da die Beobachtungen ”‘im Feld”’ erfolgt, sind die Ergebnisse
realistisch. Aber die Verallgemeinerung der Resultate ist auch hier
schwierig, da in den meisten Fällen der ”‘im Feld”’ beeinflussende Kontext schwierig zu verstehen ist. Eine Feldstudie ist auch eine Beobachtungstudie.
3. Umfrage
Bei einer Umfrage beantworten die Umfrageteilnehmer mehrere von
den Forschern sorgfältig formulierte Fragen. Die Ausführung kann
schriftlich (via Fragebogen) oder mündlich (via Interview) erfolgen. Sie
ist einfach und relativ billig, aber die Verlässlichkeit der Ergebnisse ist
unklar, da die Ergebnisse meist ungenau, subjektiv und sogar manchmal absichtlich verfälscht sind. Eine Umfrage kann bei dem Experiment
die Grundlage für eine zukünftige Verbesserung sein, wenn man sie nach
einem Test ausführt.
4. Metastudie
Eine Metastudie ist eine Studie der Softwareartefakte anhand mehrerer
früherer Studien zu demselben Thema, die sich aber in Methodik, Anwendungsfall, Art der Beschreibung und anderer Eigenschaften unterscheiden können. Sie verursacht relativ geringen Aufwand und ist
deswegen im Prinzip billig und nützlich, setzt aber zunächst genügend
viele andere Studien voraus.
5. Kontrolliertes Experiment
Ein kontrolliertes Experiment ist eine Studie, bei der alle für das Ergebnis relevanten Umstände konstant gehalten (kontrolliert) oder manipuliert werden. Die Beobachtungen werden mit verschiedenen Einstellungen der Umstände (Behandlungen) miteinander verglichen, um so
zu reproduzierbaren Resultaten zu kommen. Kontrollierte Experimente
bieten den höchsten Grad an Kontrolle unter allen empirischen Methoden. Sie sind recht aufwändig, da viele Umstände vorher auf die
Relevanz untersucht und kontrolliert werden müssen. Ausserdem sind
sie auch teuer. Aber sie lassen sich wegen der Kontrolle sehr genau
verstehen und relativ gut reproduzierbar. Ein Experiment umfasst
eine Menge von Teilnehmern (Versuchspersonen) sowie den zu bearbeitenden Aufgaben. Die Versuchspersonen werden in einem Experiment den Versuchgruppen fast immer rein zufällig zugeordnet (Randomisierung). Wenn es nicht möglich ist, und arbeitet man mit ganz
27
Grundlagen
oder teilweise vordefinierten Gruppen, solch einen Experimententwurf
bezeichnet man als quasi-experimentellen Entwurf.
1.2
Wichtige Begriffe in kontrollierten Experimenten
Ein kontrolliertes Experiment soll dafür sorgen, dass jede Beobachtung (jeder
Effekt) durch eine eindeutige Ursache (einen eindeutigen Grund) verursacht
wird, d.h. Wenn etwas zweimal durchgeführt wird und dabei alle Umstände
bis auf einen (U) gleich sind, dann müssen eventuell Unterschiede in den
Ergebnissen (E) vorliegen.
In einem kontrollierten Experiment gibt es drei Arten von Parametern,
die wie folgt bezeichnet werden:
• Abhängige Variable
Die im Laufe des Experimentes gemessenen Größe (E).
• Unabhängige Variable
Die im Laufe des Experimentes manipulierten Größe (U). Beispiel: Der
Effekt einer neuen Entwicklungsmethode auf die Produktivität des Personals wird studiert. Dazu wird beispielsweise eine objekt-orientierte
Entwurfsmethode statt einer funktional-orientierten gewählt. In dem
Experiment ist die abhängige Variable die Produktivität und die unabhängigen Variablen sind die Entwicklungsmethode, die Erfahrung des
Personals, die unterstützende Werkzeuge und die Umgebung.
• Störvariable
Die im Laufe des Experimentes konstant gehaltenen Größe. Bei einem
kontrollierten Experiment sollen alle Umstände prinzipiell konstant
sein. Diese Umstände heißen die Störvariablen. Hier ist es zu bemerken, dass die meisten Störvariablen irrelevant sind; zum Beispiel:
Ist es für das Experiment relevant, ob eine Versuchspersonen 1,60 m
groß oder 1,95 m ist?
Aber die genaue Liste der in einem kontrollierten Experiment relevanten Störvariablen ist nicht immer bekannt. Glücklicherweise ist es nicht
nötig diese Liste zu kennen, weil sich fast alle Störvariablen, ob bekannt
oder nicht, durch dieselben Technik kontrollieren lassen. Die Technik
besteht aus der Replikation und der Randomisierung. Die Replikation
bezeichnet die Betrachtung einer ganzen Gruppe (nicht einer einzelnen
Versuchperson). Die Randomisierung bezeichnet die zufällige Auswahl
der Mitglieder dieser Gruppe. Wenn die Gruppen nicht allzu klein sind,
gleichen sich die Einflüsse aller relevanten Störvariabeln innerhalb jeder
28
1 Einführung
Gruppe im Mittel aus. Bespiel: Die Störvariable X verändert unerkannterweise das beobachtete Ergebnis und zufällig war die Störvariable
X für die verglichenen Gruppen nicht genau gleich. Diese Störvariable
kann mit statistischen Techniken quantifiziert und beherrscht werden.
Figure 1: Das Prinzip eines Experiments.
1.3
Experimentprozess
Ein Vorgehensrahmen für Experimentationen in der Softwaretechnik ist wie
folgt aufgestellt [3]:
1. Definition
Der erste Schritt einer Experimentation ist die Experiment-Definition.
Hier erfolgt die Auswahl einer Fragestellung mit den zugehörigen Umständen. Sie besteht aus den folgenden Teilen [4, 5]:
• Analysiere <Studie-Objekt(e)>
die Entität, die im Experiment beobachtet wird.
• mit dem Ziel <Ziel>
Zweck, Absicht, Intention des Experiments.
• in Bezug auf <Qualitätsfokus>
Effektivität, Kosten, Verlässlichkeit, etc.
29
Grundlagen
• nach Ansicht von <Perspektive>
Forscher, Entwickler, Verbraucher, Projekt-Manager(in), etc.
• in dem Kontext <Kontext>
Situation/Umgebung, wo das Experiment ausgeführt wird. Hier
werden die Teilnehmer, die Software-Artefakte mit deren Eigenschaften definiert.
2. Planung (Entwurf)
In dieser Phase legt man fest:
• welche Gruppen ausgewählt werden,
• in welcher Reihenfolge ausgeführt werden,
• welche Aufgaben zu erledigen sind bzw. welchen ”‘Behandlungen”’
unterworfen werden, und
• welche abhängigen Variablen dabei beobachtet werden.
3. Durchführung
Diese Phase besteht aus der Vorbereitung, der eigentlichen Ausführung,
der Datenvalidierung und der Analyse. Hier muss es gewährleistet
werden, dass das Experiment gemäß den Plänen und dem Entwurf
aufgebaut ist, und die gesammelten Daten sind korrekt und statten
ein gültiges Experiment aus.
4. Interpretation
Rohe Resultate der Analysen sind meistens nicht genug, um die Resultate zu verstehen und die Schlussfolgerungen des Experiment zu
begreifen. Deshalb muss eine Interpretation erstellt werden. Sie
beschreibt, wie die Experiment-Resultate angewandt werden. Sie betrifft beispielsweise die Extrapolation, die Wirkung, etc.
Wie man sieht, gibt es viele Arten einen Rahmen für ein Experiment
aufzustellen (z.B.: [1] ”‘Arbeitschritte zur Durchführung”’ Seite 65-69, etc),
aber trotzdem sind alle prinzipiell ähnlich.
1.4
Gültigkeit
Eine wesentliche Frage bezüglich der Ergebnisse eines kontrollierten Experiments ist, wie gültig die Ergebnisse sind. Man unterscheidet die Gültigkeit
in vier Typen:
30
1 Einführung
1. Schlussfolgerungsgültigkeit
Dieser Typ von Gültigkeit bezieht sich auf die Frage, ob die statistische Verarbeitung korrekt war. Eine Gefährdung für die Schlussfolgerunggültigkeit stellen also die Umstände dar, die das korrekte Verhältnis zwischen der Verarbeitung und dem Ergebnis beeinträchtigen.
Sie sind [2]:
• ”‘Fischen”’
Die Forscher können das Ergebnis beeinträchtigen, indem sie ein
bestimmtes oder erwünschtes Ergebnis suchen (fischen). Dies
führt zu Ungültigkeit der Analysen.
• Verlässlichkeit der Messungen
Die Gültigkeit eines Experiments ist stark abhängig von der Verlässlichkeit der Messungen. Diese ist beispielsweise abhängig von
einer schlechten Instrumentation. Im Prinzip misst man zweimal
ein Phänomen, dann soll das Ergebnis gleich sein. Also sind
die objektive Messungen, mit denen das gleiche Ergebnis wiederhergestellt werden kann, sicherer als subjektive Messungen, zum
Beispiel: Zeilen von Codes sind sicherer als Punkte einer Funktion.
• Verlässlichkeit der Ausführung der Behandlungen
Hier beschäftigt man sich mit der Ausführung einer Behandlung
der Versuchspersonen. Es passiert oft, dass die Ausführung der
Behandlungen zwischen den Versuchspersonen nicht gleich ist.
• Zufällige Irrelevanzen in der Experiment-Umgebung
Umstände außer der Experiment-Umgebung können das Ergebnis
beeinträchtigen, wie zum Beispiel Lärm außerhalb des Raumes
oder plötzliche Störungen im Experiment (Handy oder Telefon
klingelt).
2. Innere Gültigkeit
Dies bezieht sich auf die Frage nach der Kontrolle der Störvariablen.
Bedrohungen, die diesen Gültigkeitstyp betreffen, sind also die Umstände, die die Kontrolle in einem Experiment beeinträchtigen. Diese
sind [1]:
• Historie
Das Vergehen von Zeit kann auch Wirkungen auf dem Experiment haben, die außerhalb des eigentlichen Experiments liegen,
aber dennoch das Verhalten der Teilnehmer beeinflussen. Zum
Beispiel: Das Experiment dauert ein Monat, und in einer Woche
gibt es ein besonderes Ereignis (Feiertage oder ähnliches). Die
31
Grundlagen
Ergebnisse können dementsprechend im Laufe der Zeit verschieden
sein, obwohl die Behandlungen konstant gehalten werden.
• Reifung
Die Reifung betrifft Veränderungen im Verhalten der Versuchspersonen, die über die Zeit auftreten. Diese sind Ermüdung, Lernund Reihenfolgeeffekte (siehe Abschnitt 2.4). Sie treten vor allem
in Erscheinung, wenn eine Versuchsperson mehrere Aufgaben
hintereinander löst (siehe auch Abschnitt 2.4: Intra-SubjektEntwurf)
• Instrumentation
Die Instrumentation betrifft die Veränderungen im Verhalten der
Experimentatoren oder dem Experimentaufbau selbst (Artefakte),
die über die Zeit auftreten. Beispiel für eine Veränderung im Verhalten des Experimentators: die subjektiven Urteile des Experimentators ändern sich allmählich im Verlauf mehrerer Beurteilungen. Beispiel für eine Veränderung im Verhalten des Experimentaufbaus: Ein Programmierwerkzeug kann bei späteren Versuchsdurchführungen aufgrund der zunehmenden Dateifragementierung
langsamere Antwortzeiten haben.
• Auswahl
Die Zuordnung der Versuchpersonen in die Gruppen kann bei
einem bestimmten Experiment nicht (wirklich) zufällig erfolgen:
Unterschiedliche Interessen oder Vorkenntnisse könnten bei einem
Experiment schon nötig sein. Hier muss man darauf achten, dass
sich die Kriterien für die Gruppeneinteilung nicht auf die Ergebnisse auswirken. Beispielsweise will man eine objektorienterte Programmiersprache mit einer funktionalen Programmiersprache vergleichen. Dazu hat man Schwierigkeiten, zwei Versuchgruppen zu
finden, von denen manche in ”‘ihrer”’ Sprache gleich viel, manche
wenig Erfahrungen haben und ansonsten hinsichtlich Intelligenz
und Erfahrungshintergrund genügend ähnlich sind.
• Sterblichkeit
Sie betrifft das Ausscheiden der Versuchperson während des Experiments. Falls die Gründe des Ausscheidens in verschieden
Gruppen unterschiedlich sind, ist die Gültigkeit in jedem Fall
bedroht. Falls das Ausscheiden nun nur aufgrund von (beispielsweise) Frustration erfolgt, ist das Experiment ungültig, da tendenziell nur leistungsfähigere Personen übrig bleiben, was die
äußere Gültigkeit zerstört.
32
1 Einführung
• Anforderungscharakteristik
Diese Bedrohung tritt dann auf, wenn die Experimentatoren
bezüglich der Versuchvariablen nicht neutral eingestellt sind, sondern sie erwarten von einer Gruppe eine bessere Leistung als von
einer anderen. Diese ‘Lieblingsgruppe”’ hat dann eine große Motivation, und wird somit zu einer relevanten und nichtkontrollierten
Störvariable.
• Verarbeitungsfehler
Es kann natürlich passieren, dass die abhängige Variable nicht korrekt gemessen oder falsch weiterverarbeitet wird. Dies betrifft
zum Beispiel: Tippfehler, Verwechslung von Daten, falsch angewandte statistische Methoden bei der Auswertung.
3. Konstruktgültigkeit
Sie beschreibt die Effektivität eines Experimentaufbau (Plan bzw. Entwurf). Foglich bezieht sie sich auf die Frage, ob der Entwurf prinzipiell
geeignet zur (teilweisen) Beantwortung der Forschungsanfrage ist. Die
Bedrohungen sind [2]:
• Mangelhafte Erklärung (Definition) des Experimentaufbau
Diese Bedrohung tritt auf, wenn die Konstruktion des Experiments nicht ausreichend definiert wird bzw. wenn die Theorie
nicht klar genug ist. Zum Beispiel: beim Vergleich zweier Inspektionsmethode ist es nicht klar, was hier ”‘besser”’ heißen soll. Soll
es heißen, die meisten Fehler, die meisten Fehler pro Stunde, die
ernsthaftesten Fehler zu finden?
• Interaktionen von verschiedenen Behandlungen
Diese Bedrohung tritt dann nur auf, wenn die Versuchperson auch
zu einer anderen Studie gehört. Die Behandlungen von unterschiedlichen Studien können eine Interaktion erfolgen. Es ist dann
nicht klar, ob das Ergebnis von den Behandlungen oder von einer
Kombination der Behandlungen kommt.
• Interaktionen von Testen und Verarbeitung
Das Testen selbst (Implementation der Behandlungen) kann auch
die Versuchpersonen empfindlicher und empfänglicher gegenüber
die Behandlungen machen, da das Testen auch zu der Behandlung
gehören. Zum Beispiel: Wenn das Testen die Messung der Anzahl
der in der Kodierung gemachte Fehler umfasst, dann werden die
Versuchspersonen vorsichtiger sein und deshalb versuchen sie, die
Fehler zu verringern.
33
Grundlagen
• Eingeschränkte Verallgemeinerung über die Konstruktionen
Die Behandlung kann die studierte Konstruktion positiv beeinflussen, aber in manchen Fällen die andere Konstruktion ungewollt negativ. Zum Beispiel: eine Studie schließt eine Folgerung
ab, dass die bessere Produktivität mit einer neuen Methode erreicht wurde. Aber andererseits kann es beobachtet werden, dass sie
die Wartbarkeit reduziert, wobei es die ungewollte Nebenwirkung
ist.
4. Äußere Gültigkeit
Hier geht es um die Bedrohungen der Verallgemeinerung der Experimentergebnisse, ob die Resultate sich korrekt auf andere Anwendungsfälle (äußere) übertragen lassen. Dies betrifft:
• Interaktion von der Auswahl und der Behandlung
Dies tritt dann auf, wenn man die Versuchspersonen aus der Population wählte, die nicht repräsentativ zu der Population, die man
verallgemeinern wollte. Also nehmen die falschen Personen an dem
Experiment teil. Zum Beispiel: bei einem Inspektion-Experiment
werden nur Programmierer benutzt, wobei sie sowohl als Tester
als auch System-Ingenieur an dem Experiment teilnehmen.
• Interaktion von der Einstellung und der Behandlung
Dies tritt dann auf, wenn man keine in dem Experiment zu benutzende Einstellung (oder Materialen) hat, die repräsentativ zu
(beispielsweise) der industriellen Einstellung ist. Zum Beispiel: in
einem Experiment werden die altmodischen Werkzeuge benutzt,
während die modernen Werkzeuge bereits verbreitet in der Industrie sind.
2
Experimententwurf
Es ist nötig, dass in einem Experiment viele Umstände betrachtet werden
müssen, um die Kontrollen zu haben und die Gültigkeiten der Ergebnisse zu
halten. In einem Experimententwurf sind die folgenden Begriffe wesentlich:
• Faktor und Niveau
Ein Faktor ist eine in dem Experiment manipulierte unabhängige Variable und jeder ihrer Werte heist Niveau (Level). Ein Faktor mit zwei
Niveaus heist dichotom.
34
2 Experimententwurf
Figure 2: Die Stelle, wo man die Art der Gültigkeit beachten muss.
• Effekt
Der Effekt ist die Veränderung in der abhängigen Variablen zwischen
zwei Niveaus eines Faktors.
2.1
Versuchspersonen
Zunächst soll man sich bei dem Entwurf mit der Auswahl der Versuchspersonen beschäftigen.
2.1.1
Kompetenz
Um die geeigneten Versuchspersonen zu erhalten, betrachte man zuerst die
Kompetenzen der Versuchspersonen. Kontrollierte Experimente werden in
den meisten Fällen mit studierenden als die Versuchspersonen vorgenommen.
Diese Experimente sind eigentlich unproblematisch, da die Unterschiede zwischen Studierenden und Profis nicht besonders groß sind(siehe [1, 8]).
Man bemerkt auch, dass nicht die absolute Leistung der Versuchperson
entscheidend ist, sondern die Veränderung der Leistung bei der Änderung der
unabhängigen Variablen. Experimente mit Anfängern sollte man vermeiden,
da ihre Arbeitsweise mit großer Wahrscheinlichkeit völlig andersartig als die
von Erfahrenen ist, und somit wird die innere Gültigkeit bedroht. Die innere Gültigkeit wird auch bedroht, wenn man die Versuchpersonen (egal ob
Studierende oder Profis) überfordert.
35
Grundlagen
2.1.2
Homogenität
Um klare und aussagekräftige (scharfe) Experiment-Ergebnisse zu erhalten,
soll man dafür sorgen, dass die Leistungsunterschiede zwischen den Versuchspersonen möglichst klein sind (homogen). Es ist also sinnvoll, auf Versuchspersonen zu verzichten, deren Qualifikation vermutlich stark von der
übrigen abweicht, da sie die Variabilität der Ergebnisse erhöhen.
In der Realität sind leider diese Tatsache kaum zu vermeiden, es gibt nämlich erhebliche individuelle Unterschiede zwischen Softwareleuten. Glücklicherweise gibt es einen Weg, dieses Problem zu beheben. Wenn die zu erwartende relative Leistung der Versuchspersonen bereits vor dem eigentlichen
Experiment bekannt ist, dann kann man einen großen Teil der Unterschiede
aus den Ergebnissen herausrechnen und trotz starker Schwankungen zu scharfen Aussagen kommen. Dies kann man anhand eines Vortests erreichen. Ein
Vortest ist eine (bzw. mehrere) Aufgabe, der vor Beginn des eigentlichen Experiments unterworfen und von allen Versuchspersonen bearbeitet wird, und
zwar ohne Unterschied in der Behandlung der Versuchspersonen. Ein Vortest
soll idealerweise von gleicher Art sein wie die im Experiment zu bearbeitenden Aufgabe, und auch die gleichen abhängigen Variablen beobachten.
Ein Vortest ist sehr empfehlenswerte, wenn er überhaupt im Experiment
möglich ist. Er bietet nämlich folgende Vorteile:
1. Er kann Lerneffekte vermindert.
Lerneffekte sind eine Folge von einer Situation, in der die Versuchspersonen im Experiment oftmals an ungewohnten Aufgaben oder unter
ungewohnten Bedingungen arbeiten. Eine solche Situation führt zum
Lernen im Laufe des Experiments, es macht die Leistung der Versuchspersonen über die Dauer des Experiments nicht konstant, sondern sie verbessert sich schnell. Lerneffekte können die Ergebnisse
verfälschen oder den eigentlich vorhandenen Unterschied zwischen den
Versuchsbedingungen verdecken.
2. Er dient als Grundlage einer Gruppenbalancierung.
Die Einteilung der Versuchspersonen in eine Versuchsgruppe kann
manchmal aufgrund der Zufälligkeit zur nicht ausgeglichenen Zuteilung
führen. Es kann sein, dass eine Versuchsgruppe spürbar leistungsfähigere Versuchspersonen zugeteilt werden als der anderen. Insbesondere passiert es oft, wenn die Gruppe klein ist. Dies kann man vermindern, wenn man dafür sorgt, dass die Gruppen nach den Anhaltspunkten gleich stark besetzt werden (Gruppenbalancierung). Diese Anhaltspunkte erhält man idealerweise von den Ergebnissen eines Vortests.
Falls ein Vortest nicht möglich ist, dann muss man als Anhaltspunkt
36
2 Experimententwurf
nehmen, was man sonst kriegen kann (z.B. durch Vorstellungsgespräch). Hier hilft auch eine grobe subjektive Einteilung: Wenn man
jemanden zur Hand als Versuchsperson hat, den man bereits gut kennt.
3. Er kann als Grundlage Paarbildung verwendet werden.
Der große Unterschied in der Leistung zwischen den Versuchspersonen
erschwert, zu scharfen Aussagen zu gelangen. Hier bietet die Paarbildung als ein Ausweg: man vergleicht jede Versuchsperson mit einer
anderen, die ihr ähnlich ist. Man betrachte dann diese beiden (Paar)
als ein und dieselbe Person. Die beste Grundlage für eine solche Paarbildung sind die Ergebnisse eines Vortests.
2.1.3
Motivation
Neben den Kompetenzunterschieden muss man noch auf die Motivationsunterschiede zwischen den Gruppen achten, da sie die innere Gültigkeit bedrohen können. Die Bedrohung bezeichnet man den Motivationseffekt. Die
Experimentatoren können (bewusst oder unbewusst) durch ihr Auftreten
und Reden die Versuchspersonen für oder gegen eine der Versuchbedingung
einnehmen. Also hängt das Ergebnis des Experiments nicht von den Versuchbedingungen ab, sondern von der Haltung der Experimentatoren, was
nicht gewünscht war. Zum Beispiel: beim Vergleich zweier Programmiersprachen C++ und JAVA kann es sein, dass die Experimentatoren beispielsweise C++ favorisieren. Durch Reden der Experimentatoren in der Experimenteinleitung wird die Meinung der Versuchgruppen beeinflusst. Ein solcher
Fall kann durch Zurückhaltung der Experimentatoren vermieden werden.
Dieser Motivationseffekt kann auch ohne Beeinflussung der Experimentatoren vorkommen, wenn beispielsweise die Versuchspersonen selbst eine
vorgefasste Meinung mitbringen, nachdem sie die Versuchbedingungen erfahren. Dies kann man mit dem Verschweigen der Experimentvariablen
vermeiden, das aber meistens unmöglich in der Softwaretechnik ist. In
diesem Fall muss man also direkt die Ursachen unterschiedlicher Motivation bekämpfen. Zum Beispiel: die Versuchteilnehmer haben die Erwartung,
dass ”‘die Kontrollgruppe keine Chance hat”’, weil die Versuchbedingung der
Experimentgruppe einen so tollen technischen Fortschritt repräsentiert. In
einem solchen Fall ist die Bekämpfung offensichtlich: die Experimentatoren
müssen den Versuchteilnehmern klar machen, dass der Ausgang des Experiments nicht von vornhinein bekannt ist (sonst braucht man das Experiment
nicht auszuführen). Hier wird also die vorgefasste Meinung der Versuchteilnehmer durch gezieltes Gegenreden in der Experimenteinleitung neutralisiert.
Selbst wenn man keine signifikanten Motivationsunterschiede hat, wird
37
Grundlagen
das Experiment dann noch bedroht, falls die Motivation aller Gruppen extrem hoch oder extrem niedrig ist, denn sie kann zu Ergebnissen führen,
die für die Praxis bedeutungslos sind. Eine extrem hohe Motivation
wird ohne Mitwirkung der Experimentatoren (siehe auch Abschnitt 1.4 Innere Gültigkeit: Anforderungscharakteristik) kaum auftreten. Eine extrem
niedrige Motivation kann man mit Teilnahmeanreize bekämpfen. Die sind:
• Geld
Dieser Anreiz ist meistens problematisch, da er zu einer unnatürlich
hohen Motivation oder zu einer niedrigen Motivation mit AbzockerMentalität führen kann.
• Symbolische Gaben
Sie betrifft eine dingliche Anerkennung (Sachwerte). Eine geringe Gabe
reicht meistens schon aus, um die Motivationsbremse zu neutralisieren.
• Lernen
Hier betrifft die Überzeugung, dass die Teilnehmenden durch die Experimentteilnahme etwas Nützliches oder Interessantes lernen können.
Dieser Anreiz ist besonders gut geeignet, wenn der erwartete Lerneffekt (siehe vorherige Abschnitt Homogenität: Vortest) in allen Gruppen
ungefahr gleich ausfallt.
Figure 3: Die wichtigen Eigenschaften von Versuchpersonen, deren
Wirkungen und die Konsequenzen für die Qualität (Gültigkeit) des
Experiments
38
2 Experimententwurf
2.2
Aufgabenstellung
Der weitere Umstand, den man in einem Experiment betrachten muss, ist
die Frage nach der Aufgabenstellung. Die Aufgabenstellung bei einem Experiment besteht meistens in der Regel aus zwei (bzw. drei) Teilen:
• einem Anweisungstext, der beschreibt, was zu tun ist,
• einem oder mehreren Softwareartefakten, die als Ausgangspunkt dienen
(z.B. Anforderungsbeschreibungen, Entwurfsdokumente, etc),
(•) Unterstützungsmaterialien
Werkzeuge oder ähnliches).
(z.B.
Handbücher
für
verwendete
Die Aufgabenstellung kann von dreierlei Art sein:
• Herstellung eines zusätzlichen Artefakt
• Veränderung oder Erweiterung eines gegebenen Artefakt
• Analysierung eines gegebenen Artefakt
Mischformen sind hier auch möglich.
2.2.1
Repräsentativität und Verallgemeinbarkeit
Bei näherer Betrachtung liegt die wichtigste Bedrohung der äußere Gültigkeit
nicht an den Versuchspersonen, sondern an den Aufgaben. Die Struktur
und der Inhalt der Aufgaben beeinflussen stark die Verallgemeinerbarkeit der
Ergebnisse. Hier unterscheidet man zwei Arten der Verallgemeinerbarkeit:
• Lokale Verallgemeinerbarkeit
Hier geht es um die Details der Aufgabenstellung (der Inhalt). Eine
falsch gewählte Aufgabe kann das Ergebnis stark abweichen lassen, was
man als repräsentativ für die zu untersuchende Klasse von Tätigkeiten
ansehen müsste. Als hypothetisches Beispiel wird ein Vergleich der
Effizienz und Effektivität von Test/Debugging versus Inspektion betrachtet [1], also geht es um Programmdefekte (Fehler):
– Versehentliche Multiplizieren anstatt Dividieren bei der Berechnung eines gleich ausgegebenen Ergebnisses.
Solche Fehler werden meistens im Test sofort entdeckt, lokalisiert
und bereinigt. Hingegen braucht eine Inspektion erhebliche
Aufmerksamkeit, um solche Fehler zu entdecken.
39
Grundlagen
– Subtile Deffekte, die nur unter sehr speziellen Bedingungen zum
Versagen führen.
Im Gegensatz zu dem obigen Fehler sind solche Fehler im Test
schwierig zu entdecken.
– Defekte, die erst nach einiger Zeit zum Versagen führen
Diese Fehler sind beim Debugging schwierig zu lokalisieren.
Hier ist die Wahl der Aufgabe (des zu untersuchenden Programms) kritisch für die Verallgemeinerbarkeit des Resultats.
Werden die Fehler in dem zu untersuchenden Programm künstlich
eingepflanzt (defect seeding), dann können die Experimentatoren absichtlich oder nicht die Aufgabe manipulieren. Im günstigen Fall steht
noch die Frage, ob die eingepflanzten Defekte ihrer Natur realistisch
sind. Ein solches Experiment wird keine hohe Glaubwürdigkeit erreichen, deshalb sollte man Fehlereinpflanzung vermeiden.
• Globale Verallgemeinerbarkeit
Sie handelt sich um die Übertragung des Ergebnisses auf ein anderes Anwendungsbereich. In der Softwaretechnik gibt es viele Unterschiede, was die Übertragung (Verallgemeinerbarkeit) unmöglich erscheint. Diese Unterschiede betreffen sowohl die Personen, die Softwarebauen, die Methoden und Prozesse als auch die Struktur und
Eigenschaften der Produkte. Diese dramatischen Unterschiede zwischen den verschiedenen Anwendungsbereichen stellen sich eigentlich
nur bei einer globalen Betrachtung ein, wenn man genauer die einzelnen Elemente eines Softwareprozesses oder die einzelnen Merkmale der
Softwareprodukten untersucht, dann gibt es zwar noch große Unterschiede, aber nicht mehr viele verschiedene Klassen. Zum Beispiel bei
der Sicherheit in einem Projekt: ob die Sicherheit eine kritische Eigenschaft oder von nur mäßiger Bedeutung (mit ein paar Ausnahmen) ist.
Im Prinzip kann man Aufgaben finden, deren Ergebnisse sich auf einen
erheblichen Teil aller Softwareprojekte verallgemeinern lassen, da bei
einem kontrollierten Experiment meistens nur ein enger Aspekt untersucht wird. Also sollte man den Einfluss minimieren, der nicht für die
Experimentfrage relevanten Eigenschaften der Aufgabe. Dazu untersucht man, welche Aufgabenstellung am wenigsten zur Festlegung auf
ein bestimmtes Anwendungsfeld führt (Isolation) und welche Bedingungen am besten zur Verallgemeinerbarkeit der Experimentergebnisse
beitragen.
40
2 Experimententwurf
2.2.2
Nötiges Vorwissen
Ein Aspekt, der bei Verallgemeinerung wichtig ist, ist das nötige Vorwissen.
Muss viel Vorwissen vermittelt werden, so gibt es zwei Gefahren:
• Diese Vermittlung verbraucht viel Zeit und Konzentrationsvermögen
der Teilnehmer. Dadurch wird der praktikable Umfang der eigentlichen
Aufgabe begrenzt.
• Es ist schwierig, viel Vorwissen gleichmäßig in die Köpfe der Teilnehmer zu transportieren. Also wird die Homogenität der Versuchgruppen (siehe 2.1.3) beeinträchtigt, was die Variabilität erhöht und
die Trennschärfe reduziert.
Dehalb sollte man die Aufgaben aussuchen, die aus möglichst leicht verständlichen Anwendungsgebieten ist.
2.2.3
Umfang und Skalierung
Ein weiterer Aspekt, der bei der Auswahl der Aufgabe betrachtet werden
muss, ist die Komplexität der Aufgaben. Nach Kritikern ist geringe Komplexität unrealistisch und zerstört die Verallgemeinerbarkeit der Ergebnisse.
Diese Aussage ist oftmals unzutreffend, denn:
• Bei realer Softwareentwicklung kommen ja auch massenhaft Aufgaben
mit geringer Komplexität vor.
• Komplexere Aufgabe haben auch mehr Eigentümlichkeiten, die von
der Experimentfrage ablenken und die Verallgemeinerbarkeit verschlechtern.
Um diese Gründe zu realisieren, sollte man idealerweise bei der Entwicklung
der Aufgabe folgendermaßen vorgehen:
1. Die vermüteten Vor- und Nachteile weisen die einzelnen Versuchbedingungen in einer umfangreichen realen Softwareentwicklung auf.
2. Die Klasse geeigneter Aufgaben muss so umrissen werden, dass sie
sowohl realistisch ist als auch möglichst alle Vor- und Nachteile
berühret.
3. Die Aufgabe soll ”‘klein”’ gewählt werden. Dabei bedeutet ”‘klein”’
einen möglichst geringen Zeitaufwand für die Versuchspersonen.
4. Man skaliert die Aufgabe noch weiter herunter, falls es möglich ist, d.h.
man versucht, von ihrem Umfang Teile zu entfernen, die keinen Einfluss
auf das Experimentergebnisse haben.
41
Grundlagen
2.2.4
Zeitbeschränkung
Eine Zeitbeschränkung bei der Bearbeitung der Aufgaben verbessert die
äußere Gültigkeit, da sie zur Zeitdruck führt, was auch in der Realität
passiert. Außerdem verringert sie auch den Aufwand der Organisation und
Durchführung (Raumbelegung, Überwachung, etc). Andererseits ermöglicht
eine Zeitbeschränkung die Verstärkung des Qualitätsunterschieds der Ergebnisse.
Figure 4: Die wichtigen Eigenschaften von Aufgaben, deren Wirkungen
und die Konsequenzen für die Qualität (Gültigkeit) des Experiments
2.3
Implementierung und Durchführung
Nun werden die Überlegungen über die Durchführung des eigentlichen Experiments behandelt. Bei der Durchführung des Experiments gibt es zwei
mögliche Störungen:
• Verwirungen
• Messversagen
Experimente arbeiten mit Menschen und eventuell auch mit Computern,
deshalb können (werden) bei ihrer Durchführung relativ viele unvorgesehene
Dinge passieren. Aus diesem Grund ist die maximale Robustheit nötig für
den Experimentaufbau. Dies kann man durch die Anwendung folgender zwei
Prinzipien erreichen:
42
2 Experimententwurf
• Einfachheit
– Inhaltliche und strukturielle Einfachheit
Sie betrifft die Aufgabenstellungen (auch die Lösungen).
– Technologische Einfachheit
Sie bedeutet die Vermeidung der komplizierten Messaufbauten,
wie komplexe Arbeitsumgebungen und Hilfsmitteln.
• Redundanz
Sie kann zur Vermeidung der Verwirung oder des Versehens beitragen.
Insbesondere ist sie zur Vermeidung der Messversagen wichtig.
2.3.1
Infrastruktur für Teilnehmer
Hier wird das Experiment aus dem Perspektiv der Versuchspersonen betrachtet. Für Suche nach Robustheit sind die folgenden Überlegungen zu betrachten:
• Die Benutzung eines Softwarewerkzeuges ist problematisch, denn es
muss dafür gesorgt werden, dass alle Versuchspersonen damit gut vertraut sind.
• Allerdings kann das Softwarewerkzeug für das zügige Untersuchen eines
umfangreichen vorgegebenen Artefakts notwendig sein; z.B. Verfügbarkeit der Suchfunktionen (Werkzeug) eines Computers (Artefakt).
• Lösungen handschriftlich abzuliefern, werden gegenüber per Tastatur
eingegebenen Lösungen viele Versuchspersonen verlangsamen.
• Insbesondere, wenn es sich um eine formale Notation handelt (z.B.
Programmcode), ist eine handschriftliche Lösung problematisch, denn
damit sind die Änderungen an teilfertigen Lösungen viel komplizierter
vorzunehmen.
• Andererseits sind Skizzen in den meisten Fällen schneller von Hand auf
Papier anzufertigen als mit einem Softwarewerkzeug.
Diese Überlegungen bedeuten, dass das Experiment besser papierbasiert
durchgeführt wird und nur dort Computerhilfe in Anspruch vorzunehmen, wo
es für die Aufgabe nötig ist. Allerdings gibt es bei einem vollständig papierbasierten Experimentaufbau eine Einschränkung: falls sich die Aufgabe um
die Erzeugung von Programmcode handelt (auch bei anderen Fällen), hat ein
Softwareingenieur in der Realität stets die Möglichkeit, diesen sofort zu validieren (durch Kompilieren und Ausführungstest). Wenn diese Möglichkeit
43
Grundlagen
im Experiment nicht gegeben ist (was bei papierbasierten Experimenten der
Fall ist), werden die Ergebnisse eine kürzere Arbeitszeit und eine schlechtere
Lösungsqualität widerspiegeln, als in Praxis zu erwarten wäre.
Eine Überlegung zur Vermeidung der groben Fehler ist die teilweise
Wiederverwendung von Materialien aus früheren Experimenten.
2.3.2
Infrastruktur für Datensammlung
Jetzt wird das Experiment aus dem Perspektiv der Experimentatoren betrachtet. Das Messversagen ganz auszuschließen, ist unmöglich, deshalb sollte
man alternative Möglichkeiten finden, um die wichtigsten Daten zu erfassen
(Redundanz-Prinzip).
Ein wichtigster Maßstab eines Softwareprozess ist der Zeitbedarf der Versuchspersonen für die Erledigung jeder Aufgabe. Bei Experimenten, die unter
Laborbedingungen stattfinden und kurze Laufzeit haben, ist die Zeit einfach
zu messen (z.B. handschriftliche Angaben der Versuchpersonen). Bei Experimenten, die unter Bürobedigungen stattfinden und lange Laufzeit haben,
ist die Zeitmessung um einiges schwieriger. Hier sind die von Versuchpersonen berichteten Werte (Zeit) oft ungenau und müssen unbedingt durch
unabhängige Beobachtungen redundant abgesichert werden.
Um Fehler bei der Experimentdurchführung zu vermeiden, kann alternativ eine Automatisierung des Ablaufs der groben Experimentschritte ausgeübt werden. Ein Problem bei automatische Abwicklung ist, sie garantiert
nicht die Abwesenheit von Fehlern, selbst wenn sie selber ohne Versagen
abläuft: Beispielweise hat eine Person zu Beginn eine falsche Versuchspersonennummer (ID) eingegeben. Mit genügender Sorgfalt in der Vorbereitung
ist dennoch eine automatische Abwicklung eine gute Hilfe für die Experimentdurchführung.
2.3.3
Pilottest
Ein ”‘frisch”’ fertig aufgebautes Experiment hat fast immer noch Tücken und
Mängel: beispielweise enthalten die Anweisungen mehrdeutige Formulierungen, Inkonsistenzen und Schreibfehler. Aus diesem Grund sollte man nicht
sofort die ”‘echten”’ Versuchspersonen auf diesen Aufbau loslassen. Die Mängel sollten zuerst nach und nach in einer Reihe einzelner Pilottest beseitigt
werden. Dazu kann man die Versuchspersonen benutzen, die aus irgendeinem
Grund nicht in die Versuchsgruppen hineinpassen oder zumindest die den
späteren ”‘echten”’ Versuchspersonen genügend ähnlich sind, damit man ein
realistisches Bild von der Eignung des Versuchsaufbaus und der Aufgaben
erhält.
44
2 Experimententwurf
2.3.4
Datenvalidierung
Die wirksamsten Methoden zur Verbesserung der Robustheit besteht im sofortigen Valiedieren der gesamten Daten: Idealerweise während des Verlauf
des Experiments (Kompilieren und Ausführungstest bei Experimenten, deren
Aufgaben mit Erzeugung von Programmcode zu tun haben).
2.4
Entwurfspläne
Ein Experiment bestehen aus einer Reihe von Tests (Behandlungen). Ein
Experimentplan beschreibt, wie diese Tests aufgebaut und durchgeführt werden. Die Experimentpläne, die am häufigsten in Experimententwürfe benutzt
werden, sind:
• Ein-Faktor-Pläne
Den Plan behandelt nur ein Faktor. Zum Beispiel: zum Vergleich zweier
Entwurfsmethoden zur Herstellung einer Software, die eine alt und eine
neu sind, wird ein Experiment mit 6 Versuchspersonen aufgebaut (d.h.
der Faktor ist die Methode und zwar mit zwei Niveaus – neu und alt).
Versuchsperson
1
2
3
4
5
6
neue Methode
X
alte Methode
X
X
X
X
X
Hier wird die Zuordnung zufällig ausgeübt.
Für einen Faktor mit mehr als zwei Niveaus kann der Plan folgendermaßen erweitert werden:
Versuchsperson
bzw. Versuchgruppe
1
2
3
..
.
Niveau 1 Niveau 2 Niveau 3 · · ·
X
X
X
• Mehr-Faktor-Pläne
Wenn in einem Experiment mehr als ein Faktor manipuliert werden,
45
Grundlagen
dann spricht man von einem faktoriellen Entwurf oder Faktorentwurf.
Der Sinn eines faktoriellen Entwurfs ist es, Interaktionen zwischen den
Faktoren zu studieren. Sei A, B Faktoren mit zwei Niveaus und EA , EB
die zugehörigen Effekten. Sei ferner EAB der Effekt, wenn man beide
Faktoren zugleich ändert. Eine Interaktion ist ein Phänomen, wobei
EAB 6= EA + EB . Die Größe der Abweichung, EA∗B , heißt der Interaktionseffekt: EAB = EA + EB + EA∗B . In diesem Fall nennt man EA
und EB die Haupteffekte. Man unterscheidet die faktoriellen Entwürfe
noch in:
– vollständigen faktoriellen Entwürfen
Alle Kombinationen der Niveaus treten in dem Entwurf auf.
– unvollständigen faktoriellen Entwürfen
Nicht alle (teilweise) Kombinationen treten in dem Entwurf auf.
Zum Beispiel: das Experiment erforscht die Produktivität von zwei
Programmiersprachen (Java und C) in Bezug auf zwei gegebenen Aufgaben. Hier ist der erste Faktor die Wahl der Programmiersprache und
der zweite ist die Wahl der Aufgabe.
Aufgabe
Aufgabe 1
Aufgabe 2
Programmiersprache
Java
C
Versuchsperson 4,6 Versuchsperson 1,7
Versuchsperson 2,3 Versuchsperson 5,8
Dieser Plan kann auch die folgende Form haben:
Aufgabe
1
1
2
2
Programmiersprache
Java
C
Java
C
Versuchsperson
4,6
1,7
2,3
5,8
In diesem Plan ist zu bemerken, dass es sich um einen 2*2 vollständigen faktoriellen Entwurf handelt; zwei Faktoren jeder mit zwei Niveaus
(Java oder C für der erste Faktor und Aufgabe 1 oder 2 für der zweite).
Die Erweiterung dieses Planes für mehrere Faktoren mit beliebigen
Niveaus ist:
46
2 Experimententwurf
1.Faktor · · ·
a11
a12
a13
..
.
n.Faktor
an1
an2
an3
..
.
Versuchsperson
2,15
3,14
10,16
..
.
Neben der Anzahl der Faktoren unterscheidet man die Entwürfe
bassierend auf die Anzahl der zu bearbeitenden Aufgaben in zwei Klassen:
• Extra-Subjekt-Entwurf
Hier hat jede Versuchsperson nur eine Aufgabe zu bearbeiten, so dass
die miteinander verglichenen Gruppen in jedem Fall disjunkt sind.
Dieser Entwurf erlauben als Vorteil umfangreiche Aufgaben.
• Intra-Subekt-Entwurf
Wenn man in einem Experiment nicht genügend viele Versuchspersonen hat, dann kann man so vorgehen, dass eine Versuchsperson mehrere
Aufgaben löst. Folglich werden mehrere separate Messungen vorgenommen. Dieser Entwurf hat die Vorteile:
– Bei gleicher Zahl von Versuchspersonen können mehr Daten erhoben werden.
– Zufällige Unterschiede zwischen den Versuchgruppen können ausgeglichen werden können.
Allerdings muss man bei diesem Entwurf beachten, dass der Reihenfolgeeffekt hier vorkommen kann. Der Reihenfolgeeffekt ist eine Form
von der Bedrohung der inneren Gültigkeit, nämlich die Reifung. Also
kann die Reihenfolge der zu bearbeitenden Aufgaben zur Ermüdung
oder zum Lerneffekt führen.
Eine gute Gegenmaßnahme sind gegebalancierte Experimentpläne. In
einem gegenbalancierten Experimentplan werden alle verschiedenen
Reihenfolgen der Niveaus eines Faktors untersucht, in dem man jede
Versuchsgruppe in entsprechende Untergruppen aufteilt. Durch den
Vergleich bzw. das Zusammenwerfen dieser Untergruppen kann man
Reihenfolgeeffekte wahlweise anlysieren bzw. neutralisieren. Falls alle
Kombination der Reihenfolge im Experimentplan auftreten, so heißt der
Plan vollständig gegenbalanciert, andernfalls teilweise gegenbalanciert.
Ein Beispiel für einen vollständig gegenbalancierten Plan aus dem obigen Beispiel: Erforschung der Produktivität von zwei Programmiersprachen in Bezug auf zwei gegebenen Aufgaben.
47
Grundlagen
Versuchperson
A
B
C
D
E
F
G
H
Behandlung
A1/Java A2/Java
A1/C
A2/Java
A2/C
A1/C
A2/Java A1/Java
A2/Java
A2/C
A1/Java A1/Java
A1/Java
A1/C
A2/Java
A1/C
Versuchperson
I
J
K
L
M
N
O
P
Behandlung
A2/C
A2/Java
A1/Java
A2/C
A1/C
A2/C
A1/C
A1/Java
A2/Java A2/Java
A2/C
A2/C
A1/C
A1/C
A2/C
A1/Java
Dabei bedeutet ”‘A1/C A2/Java”’, dass die Versuchperson zuerst die
Aufgabe 1 mit C und später die Aufgabe 2 mit Java arbeitet.
In der Praxis benutzt man fast nie vollständig gegenbalancierte Pläne,
denn viele der Kombination wären sinnlos. Zum Beispiel: Von der Behandlungen der Versuchpersonen A, C, D, E, F, G, I, K, L, M, N und
O aus dem obigen Beispiel sind keine Erkentnisse zu erwarten. Aus
diesem Grund sollte man nur die Kombination in den Experimentplan
aufnehmen, die voraussichtlich wichtig sind (Zum Beispiel: die Behandlungen der Versuchpersonen B, H, J und P aus dem obigen Beispiel).
3
Beispiel Entwurf: C versus C++
Hier als Beispiel wird der Vergleich zweier Programmiersprache C und C++
eingeführt [2], die eine funktional und eine objektorientierte sind (siehe auch
der Vergleich C++ mit SML [6]). Die Studie geht von einer Hypothese aus,
dass C++ besser als C wegen des Vorteils der Objekt-Orientierung ist, und
wird innerhalb des PSP-Kontexts1 ausgeführt.
Als Versuchspersonen werden Studenten ausgewählt. Sie entwickeln
unabhängig voneinander zehn verschiedenen Programms(die PSP-Aufgabe
#1A-#10A). Diese Aufgaben werden immer erweitert; von einem einfachen
Prozess in der ersten Aufgabe #1A bis zum komplexen Prozess in der letzten Aufgabe #10A. Trotz dieser Erweiterung hat jede Aufgabe die folgende
gemeinsamen Phasen (für die Details der Aufgaben: [7]):
1. Planung
Diese Phase befasst sich mit der Planung von der Entwicklung des
Programms in der Aufgabe.
1
Der Personal Software Prozess (kurz PSP) ist eine Arbeitsmethodik (Prinzipien und
die zugehörige Techniken), mit der ein einzelner Softwareingenieur angeblich die Vorhersagbarkeit und Qualität seiner eigenen Arbeit in fast allen Bereichen der Softwareherstellung
erheblich verbessern kann.
48
3 Beispiel Entwurf: C versus C++
2. Design
Das Design heißt Herstellen eines ”‘high level”’ Designs für das Programm in der Aufgabe.
3. Design-Review (nur für die drei letzten Aufgaben #7A-#10A)
Design-Review ist der Rückblick des hergestellten Designs.
4. Code
Diese Phase betrifft die Implementierung des Designs.
5. Code-Review (nur für die drei letzten Aufgaben #7A-#10A)
Code-Review ist der Rückblick des hergestellten Codes.
6. Kompilieren
Kompilieren heißt hier Kompileren des Programms, bis keine (syntaktischen) Fehler gefunden wurden.
7. Test
Der Test betrifft die Ausführung des Programms und die Korrektur des
Programms, bis alle (semantischen) Fehler behoben wurden.
8. Postmortem
Diese Phase befasst sich mit dem Zusammenfassen und der Auswertung
der Entwicklung.
Die Zuordnung der Studenten und der Programmiersprachen erfolgt nicht
zufällig, sondern die Studenten haben die Freiheit, die Programmiersprache
zu wählen, denn das Ziel der Studie ist nicht der Vergleich der Sprachen für
Leute, die zum ersten Mal die Sprache kennenlernen, sondern für Leute, die
mit der Sprache vertraut sind. Die Studenten bzw. die Versuchspersonen
werden zuerst über PSP in verschidenen Klassen ausgebildet. Die drei ersten
Aufgaben sind von der Studie ausgeschlossen, denn die Versuchspersonen
haben zu diesem Zeitpunkt noch keine Erfahrung über die Studie; also werden
nur die sieben letzten Aufgaben #4A-#10A in der Studie ausgewertet.
Die Variablen in der Studie sind:
• Die unabhängige Variable (der Faktor) in der Studie ist die Auswahl
der Programmiersprache mit zwei Niveaus (C und C++).
• Die mögliche Störvariable ist die Klasse, in der die ”‘PSP-Kurs”’ gehalten ist, aber man kann sie hier als eine zusätzliche unabhängige Variable
sehen.
• Die abhängige Variablen sind:
49
Grundlagen
1. Gesamtdauer:
ist die benötigte Zeit zum Entwickeln aller Programme. Sie stellt
das Gesamtkosten der Entwicklung der Programme dar.
2. Planungszeit:
ist die benötigte Zeit zur Planung der Aufgabe. Die Auswahl
der Programmiersprache hat eigentlich keine Wirkung auf diese
Variable. Der Hauptgrund, warum sie betrachtet wird, ist es zu
wissen, ob andere Faktoren (Störvariablen) außer der Auswahl der
Programmiersprache die Ergebnisse beeinträchtigen.
3. Code zum Test:
ist die benötigte Zeit zur Arbeitung der Aufgabe von Code bis zum
Test. Diese Zeit erfasst außer der Code- und Test-Phase auch die
Kompilierung und den Code-Review. Sie stellt die Kosten der
Phasen dar, die direkt von der Auswahl der Programmiersprache
beeinflußt werden.
4. Relative Code zum Test:
ist die relative benötigte Zeit der Tätigkeiten von Code bis zum
Test. Sie wird folgendermaßen definiert:
die Zeit von Code bis zum T est
der Gesamtdauer
Die Unterschiede in der Ausführung der Phasen, die von der Programmiersprache beeinflusst werden, werden sich in der relativen
Zeit von Code zum Test zeigen.
5. Gesamtdefekt:
ist die gesamte Anzahl der in der Entwicklung der Programme
eingeführten Defekte.
6. Code-Defekt:
ist die Anzahl der in der Code-Phase eingeführten Defekte.
7. Review-Effektivität:
ist ein Maßstab, wie effektiv die Code-Review-Phase ist. Sie wird
folgendermaßen berechnet:
die Anzahl der Def ekte in Code − Review − P hase
die Anzahl der Def ekte in Code − Review−, Kompilieren − und T est − P has
Sie kann es zeigen, ob es einen Unterschied in der Fähigkeit
zum Finden der Defekten in Reviews verschiedener Programmiersprachen gibt. Eine hohe Review-Effektivität bedeutet, dass der
Code gut verständlich ist.
50
3 Beispiel Entwurf: C versus C++
8. Gesamtes Qualitätskosten:
ist die benötigte Zeit zum Beheben der Defekte nach der CodePhase: Code-Review-, Kompilieren- und Test-Phasen. Sie kann es
zeigen, ob die Kosten vom Beheben der Defekte für verschiedene
Programmiersprache unterschiedlich sind.
9. Wiederverwendung:
Würde ein Programm entwickelt, ist es empfohlen, den Code von
vorherigem wiederzuverwenden. Dieser Maßstab betrifft die relative Menge von dem in alle sieben Programmen wiederverwendeten Code.
Um eine relevante Studie zu erhalten, muss man noch die Gültigkeit überprüfen:
• Innere Gültigkeit
Die mögliche Bedrohungen der inneren Gültigkeit sind:
1. Historie
Diese Bedrohung ist für diese Studie nicht so wichtig, denn keine
systematischen Richtungen wurden in der Studie identifiziert [2].
2. Reifung
Diese Bedrohung soll hier betrachtet werden, da die Studie
während eines ganzen Semester gehalten wird. Der Lerneffekt
wird hier dadurch vermieden, in dem die drei ersten Aufgaben
ausgeschlossen wird.
3. Instrumentation
Da die Studie innerhalb des PSP ohne zusätzlicher Instrumentation ausgeführt ist, wird diese Bedrohung als unwichtig betractet.
4. Auswahl
Die Einteilung der Versuchspersonen, welche mit C bzw. C++
arbeiten, soll nach dem Prinizip eines kontrollierten Experiments
zwar zufällig erfolgen, aber aus dem oben erwähnten Ziel der
Studie ist die Zuordnung in der Studie zulässig. Idealerweise
würde die Versuchspersonen aus größerer Population gewählt, dies
ist allerdings unmöglich wegen praktischen Gründe [2].
5. Sterblichkeit
Die Versuchspersonen, die die Studie ausschieden, machte diese
Entscheidung unabhängig von ihrer Auswahl der Programmiersprache, also wird diese Bedrohung als unwichtig betrachtet.
51
Grundlagen
• Äußere Gültigkeit
Bei Verallgemeinerbarkeit der Ergebnisse in dieser Studie betrachtet
man die folgende Aspekte:
1. Verallgemeinerbarkeit der Einstellung (Infrastruktur)
Die Aufgaben sind relativ klein aufgebaut und befassen die Implementierung der mathematischen Funktionen. Die Aufgaben
werden individuell von einem einzelnen Person bearbeitet, was
es bedeutet, dass das Ergebnis für kleine indivieduelle Entwicklungsaufgaben gültig ist. Ob das Ergebnis für größere Aufgaben
gültig ist, muss es noch ausgearbeitet werden.
2. Verallgemeinerbarkeit der (Versuch-)Personen
Die Studie benutzte die M.Sc.- und Ph.D. Studenten, die gut vertraut mit Software Entwicklung sind. Ob das Ergebnis für industrielle Software-Entwickler gültig ist, muss es noch ausgearbeitet
werden.
4
Zusammenfassung
Bei dem Experimententwurf muss man viele Überlegungen beachten, um die
hohe Gültigkeit der Ergebnisse des Experiments zu erhalten.
Diese Überlegungen betreffen erstens die Versuchspersonen. Die Versuchpersonen sollten möglichst gleiche genügende Leistung haben, damit man
gute Trennschärfe der Ergebnisse erhalten kann. Die Motivationsunterschiede
zwischen den verschiedenen Versuchsgruppen bedrohen die innere Gültigkeit
des Experiments. Eine schlechte Motivation kann man mit Teilnahmeanreize
bekämpfen. Bei der Zuordnung der Versuchspersonen in die Versuchsgruppen
ist ein Vortest empfohlen.
Zweitens betreffen die Überlegungen die im Experiment zu lösenden Aufgaben. Die zu lösende Aufgabe ist der wichtigste Faktor bei der Verallgemeinerung der Ergebnisse (äußere Gültigkeit). In diesem Kontext kann die
schlechte Verallgemeinerbarkeit der Ergebnisse erstens in der grundsätzlichen
Natur der Aufgabe (global: Herkunft/Anwendungsbereich) zweitens in den
Details der Aufgabestelllung (lokal) liegen. Man sollte auch den Einfluss
minimieren, der nicht relevant für die Experimentfrage ist.
Die dritte Überlegung betrifft, wie man das Experiment durchführen
sollte. Bei der Durchführung sollte man die Prinzipien von Einfachheit
und Redundanz festhalten, um die Verwirrungen zu vermeiden und von den
Messversagen zu schützen. Ein Versuchsaufbau hat anfangs Tücken und
Mängel, deshalb muss er unbedingt zunächst durch Pilottests ausprobiert.
52
References
Dazu sollte man nicht mit den ”‘echten”’ Versuchspersonen arbeiten. Bei
der Auswertung bzw. Datensammlung kann man eine automatische Abwicklung benutzen, aber dazu muss man zuerst für genügende Sorgfalt in der
Vorbereitung sorgen. Die Zeitbeschränkung der Durchführung des Experiments verbessert die äußere Gültigkeit, die aber die Qualitätsunterschiede
verstärken kann.
Der Experimententwurf kann man bzgl. die Anzahl der zu bearbeitende Aufgabe in zwei aufteilen: Extra-Subjekt-Entwurf und Intra-SubjektEntwurf. Ein Extra-Subjekt-Entwurf hat den Vorteil, umfangreiche Aufgaben in dem Experiment zu benutzen. Ein Intra-Subjekt-Entwurf hat den
Vorteil, mehr Daten zu ergeben. Bei dem Intra-Subjekt-Entwurf muss man
auf die Reihenfolgeeffekte aufpassen. Um diese Effekte zu bekämpfen, kann
man einen gegenbalancierten Experimententwurf benutzen.
References
[1] Prechelt, L.: Kontrollierte Experimente in der Softwaretechnik.
Springer, 2001.
[2] Wohlin et al.: Experimentation in Software Engineering. Kluwer Academic Publishers, 2000.
[3] Victor R. Basili, Richard W. Selby, and D.H. Hutchens. Experimentation
in Software Engineering. IEEE Trans. on Software Engineering, 12(7):
733-743, July 1986.
[4] L. C. Briand, C. M. Differding and H.D. Rombah, ”’Practical Guidelines of Measurement-Based Process Improvement”’, Software Process
Improvement and Practice, 2(4), pp. 253-280, 1996.
[5] C. M. Lott and H. D. Rombach, ”’Repeatable Software Engineering Experiments for Comparing Defect-Detection Techniques”’, Journal of Empirical Software Engineering, 1(3), pp. 241-277, 1996.
[6] R. Harison, L.G. Samaraweera, M.R. Dobie und P.H. Lewis, ”‘Comparing Programming Paradigms: an Evaluation of Funtional and ObjectOriented Programms”’, Software Engineering Journal, pp.247-254, July
1996.
[7] W.S.Humphrey, A Discipline for Software Engineering, Addison Wesley,
1995.
53
Grundlagen
[8] Sjoberg et al: Conducting realistic experiments in software engineering.
In International Symposium on Empirical Software Engineering, 2002.
IEEPress, 2002.
54
Qualitative Measurement
participant observation∗
Luoxin Cai
Abstract
There are a wide variety of methods that are common in qualitative measurement, in this paper we will discuss mainly one of the
most commonly used methods¨Cparticipant observation. In order to
give a complete view of qualitative measurement, the paper will begin
with a brief introduction for the definition and history of qualitative
measurement; various qualitative measurement methods will be introduced afterwards, then with two represented examples participant
observation will be discussed in detail. Finally, my own application
of participant observation about Extreme programming will be presented, and possible future works will be pointed out.
Keywords: qualitative measurement, history, common methods in qualitative
measurement, participant observation, application of participant observation, future work
∗
thanks for the great help from Dirk Wilking, all my workmates participanted in my
observation and Prof. Dr.-Ing. Stefan Kowalewski
Grundlagen
1
Introduction
Qualitative and quantitative measurements are both widely used in research
areas, some researchers believe quantitative measurement is better, since
it¡¯s more exact and precise, easy to calculate with the data collected; some
support the idea qualitative measurement is better, since it considers also
the subject factors during the data collecting and analysis period. In fact,
the debate between the relative advantages of qualitative and quantitative
methods is stronger than almost any other methodological topic in research,
but we all have to admit both measurements are valuable and proper in
specific areas.
In this paper, we mainly focus on the qualitative-oriented measurement
methods, give the general definition, the history, and the breaking points
along the development of qualitative measurement methods, which is explained in Section 2. Section 3 describes three commonly used qualitative
measurement methods and discusses the strengths and also shortcomings of
them. In Section 4, one of the measurement methods¨Cparticipant observation will be discussed in detail with two examples, one from the area of
social science and the other from the field of information technology, then
a small applicaiton of participant observation conducted by myself will be
presented. Section 5 points out the possible future work in the qualitative
measurement research. At the end of this paper, a conclusion about the
qualitative measurement methods will be given.
2
What is Qualitative research
It’s probably difficult to give an exact definition of qualitative measurement
, many researchers or academicians have already tried to define the meaning:
Patton (1980)has written:”Qualitative measurement has to do with the
kinds of data or information that are collected. Qualitative data consist of
detailed descriptions of situations, events, people, interactions, and observed
behaviors; direct quotations from people about their experiences, attitudes,
beliefs, and thoughts; and excerpts or entire passages from documents, correspondence, records, and case histories. The detailed descriptions, direct quotations, and case documentation of qualitative measurement are data from
the empirical world. The data are collected as open-ended without attempting to fit programmed activities or peoples’ experiences into predetermined,
standardized categories such as the response choices that comprise typical
questionnaires or tests.”
Denzin (1998)has written:”Qualitative research can be defined in gen56
2 What is Qualitative research
eral terms as multimethod in focus, involving an interpretive, naturalistic
approach to its subject matter,Qualitative researchers study things in their
natural settings, attempting to make sense of ,or interpret, phenomena in
terms of the meanings people bring to them.”
Judith Preissle has written:”Qualitative research is a loosely defined category of research designs or models, all of which elicit verbal, visual, tactile,
olfactory, and gustatory data in the form of descriptive narratives like field
notes, recordings, or other transcriptions from audio- and videotapes and
other written records and pictures or films.”
But, actually there is no nice and neat definition for qualitative research,
and the qualitative research does not involve a standard set of research techniques or methods that researchers can apply with. In my own opinion,
qualitative measurement is more subjective than quantitative measurement,
the information it produces is not obtained by means of quantification, for example, by statistical process, but mainly by individual or in-depth interviews
or focus groups or participant observation. It typically got very rich and
detailed information, and helps to gain a deeper understanding of the user
experience, but probably just because of the exploratory and open-ended
nature of qualitative measurement, it normally costs much more time and
resource for data collecting and analysis than quantitative measurement.
2.1
History of Qualitative measurement research
It’s really difficult to give a detailed and complete story about the history of
qualitative research. In this paper I will just try my best to present a whole
picture of the qualitative research development from about early 1900s to
now, and hope to include the information as much as possible:
• The first time period is from early 1900s until the World War II
Some history researchers call it ”The Traditional Period” or easily ”The
Early Decades of qualitative research”. In this period, the positivist scientific
paradigm stands on the leading part in qualitative research area, researchers
struggle to write ” objective” accounts of field experience and their observation of society, and they are willing to make their writings, their collected
data and their interpretations as valid, reliable and objective as possible.
The research problems or subjects are seen as ” alien, foreign, and strange
outsiders”, then any opinions or wills from researchers are seen as bias and
prejudices which should be eliminated from the research process.
Rosaldo (1989) describes this period researcher as Lone Ethnographer,
he has written: ” the ethnographer encountered the object of his quest...
57
Grundlagen
Returning home with his data, the Lone Ethnographer wrote up an objective account of the culture studied... This sacred bundle of terms organized
ethnographic texts around four beliefs and commitments: a commitment to
objectivism, a complicity with imperialism, a belief in monumentalism (the
ethnography would create a museumlike picture of the culture studied), and
a belief timelessness (what was studied would never change).”
This period is also the origin of classic ethnography, scholars like Malinowski, Radcliffe-Brown and Gregory Bateson are representatives. Although
today the idea of complicity with imperialism and the commitment to objectivism are sharply doubted, and the belief in monumentalism is already
passing, some researchers are still yearning for that period. Professor Cora
Du Bois has once said in a conference (1980) that:” I feel a distance from the
complexity and disarray of what I once found a justifiable and challenging
discipline.”
• The second time period is from post-War to the 1970s
This period is called ”Modernist Phase” or ”Post-positivist Period”. In this
period, the researchers like Bogdan, Filstead, Glaser and Taylor etc. sought
to formalize the qualitative methods through the use of ” quasi-statistics” and
other rigorous qualitative analysis methods. Howard S. Becker (1957) in his
famous article Problems of Inference and Proof in Participant Observation
has written: ” Participant observations have occasionally been gathered in
standardized form capable of being transformed into legitimate statistical
data. But the exigencies of the field usually prevent the collection of data in
such a form to meet the assumptions of statistical tests, so that the observer
deals in what have been called –quasi-statistics.”
The researchers in this period no longer eagerly seek for the objectivism
of all data collected and methods used, they have began to admit the impossibility to achieve the goal of total objective. Lyn Lofland (1980) once
said in his work: ” this is a moment of creative ferment-scholarly and political. The San Francisco meetings witnessed not simply the Blumer-Hughes
event but a ”counter-revolution”. A group first came to talk about the problems of being a sociologist and a Female, the discipline seemed literally to be
bursting with new ideas: labeling theory, ethnomethodology, conflict theory,
phenomenology and dramaturgical analysis.”
The period is the golden age of formalization qualitative method, and
also the ferment for the creativeness afterwards.
• The third time period is from 1970 to 1980s
58
This period includes the contention of a hundred schools of thought; qualitative researchers had various theories, paradigms, methods, strategies and
conceptions to apply with:
Theories
positivism, post-positivism, phenomenology,
ethnomethodology, critical theory, semiotics,
structuralism, feminism, etc
Strategies and formats
case study, methods of historical,
biographical, ethnographic action,
clinical research, etc.
Methods
qualitative interviewing (open-ended and quasi-structured),
observational visual, personal experience,
documentary methods, etc.
Clifford Geertz (1973) argued that:” the old functional, positivist, behavioral, totalizing approaches to the human disciplines were giving way to
a more pluralistic, interpretive, open-ended perspective. All anthropological
writings are interpretations of interpretations. The boundaries between the
social sciences and the humanities had become blurred. Social scientists were
now turning to the humanities for models, theories, and methods of analysis
(semiotics, hermeneutics).... The golden age of the social sciences was over,
and a new age of blurred, interpretive genres was upon us. ”
This period is a mixture of analysis methods, theories and ideas, but we
must point out that: the naturalistic, post-positivist, constructionist and interpretative paradigms have increase gained their strength in research areas.
And there is also another event should pay much attention, that is the appearance of computers as a help tool for data analysis and data collection in,
for example, interviews or participant observation, etc.
• The fourth time period is from mid1980s to 1995
From many research papers, we can also see there are still sub-periods in
the whole period from mid1980s to 1995, but since we only give a brief introduction about the history of qualitative research, we put these sub-periods
together in this paper. Actually this period is a sharp break from the old
and traditional qualitative research method, it’s the result of ferment creativeness, and the area of qualitative research finally welcomes a new and
impressive age. Researchers make new models of methods, representations,
59
Grundlagen
many critical theories, like feminist theory are on the table. Old conceptions
like validity, reliability, and objectivity are deeply in doubt, in the contrast,
the interpretative theories are more common and widely accepted. Rosaldo
(1989) said: ”writers continue to challenge older models of truth and meaning.”
In the area of Participant Observation, the original distant observer is
replaced by a more activated and participated field worker, and the observers
more like to write texts as small-scale tales which are proper to specific
problems and situations.
• The last time period is from 1995 until now
Concerned with this period, there is one Press Company which can’t be
missed-the AltaMira Press with the leader Mitch Allen, the book series from
AltaMira Press bring out the conception of post-experiment: ” Ethnographic
Alternatives publishes experimental forms of qualitative writing that blur the
boundaries between social sciences and humanities. Some volumes in the series...experiment with novel forms of expressing lived experience, including
literary, poetic, autobiographical, multi-voiced, conversational, critical, visual, performance and co-constructed representations.”
At present, the conflict, the debate and the great tension between methods, theories, and conceptions are more and more furious which obviously
need much future work and our new knowledge power.
At the end of this brief history introduction, there are some points should
be directed. Although we have given relative clear time partition for each
period along the qualitative research development, we can’t see the older
conceptions or theories are completely disappears at present, researchers are
still following some old methods under certain conditions; no period has
so many strategies, theories, methods to apply with as present, this is a
good luck for today’s researchers, but also a challenge for methods selection,
and data analysis; many critical issues like race, gender, ethnicity are added
to the qualitative research areas, which actually change the research into a
multicultural process.
2.2
Qualitative and Quantitative measurement
In fact, a long time ago, in 1979, Cook and Reichardt have already given the
difference between Qualitative and Quantitative research:
60
Qualitative research
phenomenological
inductive
holistic
subjective centered
process oriented
anthropological world view
relative lack of control
goal:understand actor’view
dynamic reality assumed;”slice of life”
discovery oriented
explanatory
Quantitative research
positivistic
hypothetico or deductive
particularistic
objective centered
outcome oriented
natural science world view
attempt to control variable
goal:find facts and causes
static reality assumed;relative constancy in life
verification oriented
confirmatory
However, the definitions are not exactly right, some qualitative researchers also use quantitative methods under specific conditions for data
analysis, and some quantitative researchers during the data collected period
also use qualitative theories. In my own opinion, I advocate the combination of both qualitative and quantitative methods during research process,
many times qualitative and quantitative methods served to provide complementary findings, only quantitative data or correspondingly qualitative data
is not enough to understand complex social processes and problems. Udo
Kelle (2001) in his paper Sociological Explanations between Micro and Macro
and the Intergration of Qualitative and Quantitative Methods has pointed
out the ” triangulation” metaphor, which is the central concept for method
integration. Udo Kelle at the end of his paper has written:” the best way to
obtain valid explanations of social phenomena is by combining quantitative
survey technology on the one hand and ethnographic investigations into the
structures of meanings and local knowledge in limited cultural settings on
the other.”
61
Grundlagen
2.2.1
The data of both measurements
We all know that the data for quantitative research is mostly numbers, the
researchers use lots of statistic methods to analysis, the normal sequence for
quantitative research can be presented as:
Observe events or present questionnaire →Tabulate →Summarize data
→Analysis →Draw conclusion
The data for qualitaive research is commonly Text or Narrative description(sometimes also charts and diagrams), the researchers analysis these documents to obtain complete knowledge of the social problem under investigation, the sequence can be defined as:
Observe events or asking open-ended questions→Record and
interpret→Continue to observe and ask→Give theories→Draw conclusions
2.2.2
The assumptions of both measurements
Although the trend for present is the combination of both quantitative and
qualitative methods in research process, but we should admit there are still
fundamental differences lie between these two methods, the assumptions hold
by researchers on each side are obviously not the same:
While the quantitative researchers believe the best way to collect the data
is to give fixed formalized questions or tables, the qualitative researchers are
willing to change their questions when they become more and more immersed
into the situation they are investigating; while the quantitative researchers see
any subject they are studying as a single unitary reality, and try to give a valid
and reliable evaluation, the qualitative researchers admit the unavoidable
individual perceptions from observers when they record the information, the
interpretation of the view as a qualitative research.
3
Different Qualitative measurement methods
There are a wide variety of methods commonly used in qualitative research
measurement, and also new and creative methods continuously appearing in
research areas. In this paper, the methods Participant observation,case study
and content analysis will be shortly introduced.
3.1
Participant observation
Since I will introduce Participant Observation in detail in the next section, I
just give the basic knowledge about it here.
62
3 Different Qualitative measurement methods
Smith (1978) has written:” Participant observation is a process of description, analysis, and interpretation in order to understand an everyday
activity more fully.” Stokrocki (1997) has written:” As a systematic study of
an everyday event, such research is search for patterns of contextual behavior and meaning.” Pohland (1976) defined:” Participant observation research
utilizes multi-methods, multi-persons, and multi-findings as a check for validity.”.... There are still many and many researchers or scholars gave meanings
for Participant observation, and as far as I am concerned the central idea is
”immersion”, the researchers’ immersion into local life in order to understand
and exam the real life and gets to know how things work.
3.2
Case study
Probably, case study is the most commonly used qualitative method in the
area of information science. Yin (2002) has given a definition for case study
as: ” A case study is an empirical inquiry which investigates a contemporary phenomenon within its real-life context, especially when the boundaries
between phenomenon and context are not clearly evident.” The method is
normally a descriptive type of study, which involves an in-depth descriptive
record of an individual or group of individuals.
The strength for case study is: it can help the researchers to get a detailed context-depended view of a particular phenomenon especially when it
is impossible to make experiment research. However, there are also disadvantages for case study, first of all just as what we have said, case study
is more about individual person, then it may not be representative of the
general group or population. Secondly, it’s a descriptive method, not for
explanation, so the conclusions about cause-and-effect relationships cannot
be drawn directly. Finally, the data collected by case study is mostly from
the past events, therefore it’s more about the problems or phenomenal to the
memory.
3.3
Content analysis
Mayring (2000) has written:” Qualitative content analysis is a qualitative
oriented method that applies different techniques for a systematic analysis,
mainly of text material gained by interviews, diaries, observation protocols,
or documents.” Not only in the area of information, social science, qualitative content analysis is widely applied in various research fields, like history,
arts, psychology, etc. Holsti (1969) also given a broad definition of content
analysis as: ”it is the any technique for making inferences by objectively and
systematically identifying specified characteristics of messages.”
63
Grundlagen
According to Krippendorff (1980), when applying with content analysis,
people should ask at least six questions:
1. Which data are analyzed?
2. How are they defined?
3. What is the population from which they are drawn?
4. What is the context relative to which the data are analyzed?
5. What are the boundaries of the analysis?
6. What is the target of the inferences?
The benefits from content analysis come from its priority of replication.
Being unobtrusive, and useful in dealing with large volumes of data, content
analysis can offer us a powerful technique for data reduction.
4
Participant observation
Just as what we have defined, in Participant Observation, the researchers
involve in the daily life of groups of people or an organization, a society that
is under investigation. In order to better understand the cultures or relationships in the organization, the researchers must build a good and fixed
collection with the people, participating in what they do and taking with
them about the events that have been observed. The focus is on the situations the people encounter and how they behave in them. However, since
Participant Observation has also developed during a long history, there are
also different modes in them, and two of the representatives are ” role” and ”
Affective participation”.
4.1
4.1.1
The Modes of participant observation
Participant observation as a role
In the type of participant observation as a role, we must further give two
sub-types: The ”passive” participant observer and the ”active” participant
observer for better understanding.
In the first sight, ”passive” is easily understood as: not directly interacts
with the people under study or as little as possible. Most passive observers
believe that only when she or he doesn’t interrupt the ordinary life of the
people, can they best observe the events happen between the people, they
are afraid that the emotions or bias from themselves will bring interferences
which will minimize the powerfulness of the result of their observation. The
advantage for passive observers is obvious: she or he can study the phenomenal more freely, and can withdraw from the situation easily, but on the other
64
4 Participant observation
side, since the observer is not fully immersed in the society she or he wants
to study, some events or behaviors which hidden deeply in the situation can’
be observed by the researcher.
The ”active” participant observers, on the contrast, try their best to participate in the ordinary life of people under study, and integrate his role with
other roles in the society. She or he experiences the ordinary life as other
people, while the time is passing, the research becomes more and more accustomed to the society or organization. Sometimes the researcher behaves
as an observer, sometimes she or he again plays the role as a normal person living in the society. Morris S. Schwartz (1955) in his paper Problems
in Participant Observation has described the situation as ” a shuttle process
in which the observer participates actively at one moment, shifts imaginatively the next moment to observing what he and others have been doing
and then shifts back to the interaction, thereby continuing the participation
uninterruptedly.” Also the good point for active participant observation is:
the observer can better know the subtleties among the interactions between
people.
4.1.2
Affective participation
Since this mode is called ”affective”, we can immediately get the information:
the observer must have some emotional relationship with the people observed.
Some people may ask:” what is the difference between active participant
observer and the affective observer? Since they are seem to both have close
relationship between the people under investigation.” Actually we have to
admit whether you are aware or nor, when you are continuously observing
the people, your own emotions, your sympathy, your likeness, your disgust
and many other feelings are slowly joining your observation.
Nevertheless, this kinds of distortion are not merely bad points, since
accompanied by the involvement, there are often some important events have
happened and need to be noticed, the observer should have the ability to
convert her or his involvement into valuable information.
4.2
Two examples of participant observations
As one of the most popular qualitative methods, participant observation is
applied in many research projects of different areas:
65
Grundlagen
4.2.1
Participant observation in social care
The first example is a qualitative study of older adults where participant observation played a major part of research on the health and social information
needs of dependent adults living at home. The study involved several categories of participants: the clients ( primary subjects receiving home care) and
(as secondary subjects) the formal care workers and other allied professionals including care managers, trainers in care practice and health practitioner
who have direct contacts with the primary subjects. A dual role was assumed
as the researcher was employed as a care worker. Janet Cooper (2004). By
becoming a care worker it was hoped that the researcher would be able to
see the everyday world from the position of the observed, and be able to
interpret the symbols and meanings of daily social interaction.
A purposive sampling strategy was adopted. In order that a real-life
picture would emerge, in-depth study and observational approaches were
adopted as methods. The initial period of fieldwork for participant observation took place over a period of several months, and only when it was
considered by the researcher that trust was well established, were clients and
their families asked to join the study. Nonetheless, after several months of
care work, one client and his relative declined the invitation to participate in
the study and the researcher had to withdrew from the particular situation.
Although the observers try their best to become ’wall paper’, some clients
still regarded the researchers with suspicion, and statement them as the ”spy”.
Field notes were structured around the guidelines including the spatial and
temporal aspects; the goals, feelings; the activities of the observed; the physical objects that are present in the situation. There is a constant trade-off
between fulfilling the daily requirements of care worker and satisfying the
demands made by the care agency, and simultaneously keeping the needs of
the research schedule.
4.2.2
Participant observation in a computer-mediated community
Participant observation can also be applied in the area of computer science.
The second example is a study which explored the complex multimedia performance of an interactive computer-mediated community called Palace. The
findings demonstrate how virtual architecture, visual context, virtual space
and avatars can be used in social interaction in communities on the World
Wide Web. Charles Soukup (2004)
In the research project, participant observation methods were used as a
means of understanding communicative performances. From the perspective
of the ethnography of communication, communication is understood through
66
the lived experience of the participants of the speech community. In order to
observe the lived experience of the community members, the researcher participated in and observed the interaction of a multimedia community on the
World Wide Web called ” Palace”. Logging ethnographic data often involves
observing and obtaining as much relevant data as possible. As a source of
data, the observer primarily compiled a detailed record of the verbal interaction of the room. The ”log” function of the Palace’s computer software
provided a precise record of the text-based interaction that was easily saved
and printed. Finally, the field notes recorded both the descriptions of and
the observers’ subjective impressions of the patterned communication performances. The data collection process continued until the patterns related
to the research question were recurring and exhaustive. Over the six months
of data collection, more than 800 pages of data were obtained from the field
notes, log files, images, and other documents.
4.3
My application of participant observation of Extreme
Prgramming
In order to better understand what ”Participant Observation” is, I decided to
make a real work, and to apply this method in my everyday life. Here comes
the chance, in this summer vocation, I made a two month internship in a
software company as a tester. During my working period, the developers in
the company were working on an urgent project, which should be finished in
a short time, so they decided to choose a relatively original method-Extreme
Programming to develop their software, and I had a golden chance to carefully
observe what my workmates were doing everyday, how they completed their
work, and what would be the possible disagreements among them.
4.3.1
The preparation
Since when I got into the project group, the development work has been
operated in the middle period, developers seem to already accustomed to the
environment, not so many conflicts or struggles as in the early period, which
I have heard from my boss, so I decided to make my participant observation
mainly about the effectiveness of ”pair programming” strategy applied in the
Extreme Programming development method.
Comparing many Frameworks for guiding the observation, I choose the
framework which was offered by Robinson in 1993:
• Space. What is the physical space like?
• Actors. Who is involved?
67
Grundlagen
• Activites. What are they doing?
• Objects. What objects are present?
• Acts. What are individuals doing?
• Events. What kind od event is it?
• Goals. What do they to accomplish?
• Feelings. What is the mood of the group and of individuals?
Following these guides, I asked myself those questions before the observation: what are the goals?how to collect data ?which techniques to use ?how
to interpret the information ?how to gain acceptance ?how to analyze the
data ?if is it necessary to use quantitative method for complement ?
4.3.2
The data collection
Actually it is very difficult for my data collecting, since my Germany is really
limited, many times I can’t understand what people were saying, thanks for
the understanding of my workmates, they had much patience to answer my
requirements of translating what they have said into English when I can’t
understand the meaning.
The main data collecting techniques I applied with are taking notes and
making an intensive interview at the end of my observation.The record for
the intensive interview will be presented in this paper; all names used in the
following record are pseudonyms:
Interviewee information:
Name: Felix
Age: 27
Gender: male
Work position: Programmer
Name: Franz
Age: 30
Gender: male Work position: Senior Programmer
Name: Katrin
Age: 26
Gender: female
Work position: Tester
Name: Thomas Age: 35
Gender: male
Work position: Group leader
The original record:
Interviewer:” Hallo everyone, thanks for your participation, today’s interview will be held about 40 minutes, and the content is about your feelings for
the pair programming strategy , in the following time, I will ask you questions around the topic, you can freely to speak out your ideas, please don’t
hesitate, if you have different thoughts from others.Thank you very much.”
Interviewer: ”the first question is very general, how do you think of pair
68
programming? Is it good? Or it’s really a disaster.”
Felix (Felix is really active for presenting opinions during the interview):
” Although now I am gradually used to the strategy, my partner and I cooperate better and better, at the early time, I really didn’t know why we
must apply pair programming. Since many times during my programming,
I had to stop and explained to my partner why I wrote this code, what was
the meaning of the functions, and the worst of all, my partner still couldn’t
understand why I did this, maybe he had better ideas, it needed much time
to coordination, really.”
Thomas:” I know from the very beginning, it needs some time to get into
a fluent situation, some programmer get used to it quickly, but most of my
programmers need relatively long time. ”
Interviewer:” why?”
Thomas:” not really sure, but probably because most of the programmers
are very young, 26 or 28 years old, they thought they did better when they
did by themselves, they don’t want to spend time explaining or teaching.
What do you think, Franz? You are very quickly used to pair programming.”
Franz:” en.........there are some meanings, maybe the age is a reason. You
know, different people have different programming habits, they don’t want
other people to always stare at what she or he does, especially for young person, they normally haven’t enough patience to bring the other person along
with their thoughts, they rather program alone.” (Laugh)
Felix:” yes, that was what I thought at the beginning.”
Interviewer: ” What is the greatest difficulty you have met during your
programming time? Can you give an example to confirm?”
Felix:” OK, I am always the first (laugh). The greatest difficulty I met was
at the beginning of the project, my partner and I seemed both want to stand
on a dominate position in the programming, when he was programming, and
I was watching, I intended to give instructions or my advice to him, but you
know, my partner had his own idea, and I insisted on my methods, but he,
you know (laugh again)....., so when I was on turn for programming, he also
gave ideas, but I thought my way was better and didn’t want to listen, now I
think at that time more or less I had bias on my own opinion, sometimes the
ideas suggested from my partner were really good, I should listen to. Then
the greatest difficulty for pair programming, I think, is how to develop a close
and trusted relationship between these two programmers, and depending on
different characters of the programmer, sometimes it needs relatively short
time, but sometimes much time is wasted for coordinating.”
69
Grundlagen
Katrin:”I am not working as a programmer, and not really participating in
the pair-programming, but as I have noticed, at the beginning of the period
the errors from the software are really many, then from time on they are becoming fewer and fewer. One reason, of course, is that our software becomes
stronger and stable, and another reason, I believe, is the better cooperation
between the two partners.”
Thomas:”one of my programmers even went to me and asked me whether it
was possible to change another partner, or let him alone did the job, but I
was insisted on my decision, even though he gave many reasons and some of
them, I had to admit, are convincible. ”
Interviewer: ”then what you have told him?”
Thomas: ”nothing special, I just said that even I have agreed to change another partner for you, you two will still have the same problem in the future,
and nothing will change unless you change some of your own habits and learn
to more understandable.”
Interviewer: ”have you compared this software project with some project
earlier? Is there some big improvement in this project with the strategy of
pair programming?”
Thomas: ”Since the project has not finished jet, I can’t say exactly what
the improvement is, but apparently, just as what Katrin has said, the error
probability is decreased and the programming speed is faster. I am much
confident we can finish our project as the planned schedule.”
Interviewer: ”I really hope so. Felix and Franz, what do you think is the
biggest advantage of pair programming, since you two are turly engaged in
it?”
Franz:”actually, pair programming is fit for small and young companies like
ours, since normally the time for developing software project is shorter and
efficient, then we can firstly push our products into the Market, and earn our
customers. Still, we need great courage to perform this strategy in the first
time, we all know some failed cases about pair programming from the past,
and it takes time to let our programmers get used to it. We can say, until
now our project develops well, the direction points to the right position, but
we should also pay attention to the development in the future. ”
Felix:”As my experience, although at first my partner and I can’t cooperate very well, the coordinate time doesn’t waste much time, now we work
smoothly, and I truly learn much from my partner. There is another advantage for pair programming as well, since we two are both familiar with the
70
code, even when one of us is leaving, the other one can tell the succeeded
person about the code, yes it needs some time, but it’s still quicker than
the condition that the following person has to read the code by her/himself
alone, anyway we should avoid the situation that some programmers are leaving during the development period, but who knows.”
Interviewer: ”OK, so Fanz thinks the greatest advantage for pair programming is its efficiency, and best proper for small and young firms. Felix thinks
pair programming is also good for condition changing, right?”
Franz:”yes, that’s my opinion.”
Felix:”right.”
Interviewer:”before we discussed some general opinions about pair programming, now I want to ask some details about it. When two persons sit side by
side in front of the screen, are there some roles for the two persons? Like, for
example, one person creates a method or function, the other one can check
whether the method created by the partner is really fit for the class or still
needs some change.”
Franz:”Yes, of course the pair does different thinking, they should pay attention to different things, since only one of them is technically programming,
the other is only watching. But that is actually the advantage of pair programming, the watching one normally can see the whole scene, therefore has
the capacity to think about the direction of the work, whether goes well or
some problems has happened. ”
Interviewer: ”oh, sorry, I think the following questions are more detailed
ones, and if Mr. Thomas Wolfgang and Katrin have some other things to do,
you can leave now, and thanks so much for the supporting of my job.”
Thomas and Katrin leave
Interviewer: ”OK, let’s continue. In practice, how often will you two change
your position?”
Felix:”It depends on. Pair members can discuss the problem and set the best
solution, some groups just set a fixed rule, like one member is in change of
two hours, then change. But in my group, we have tried the fixed plan firstly,
but found out that’s not a good one, since sometimes I feel tired in one day,
and can’t concentrate on programming in so much long time, sometimes my
partner feel the same way, then we make a deal to have a more flexible plan,
when the programmer often makes mistakes or something like that, we just
change our role.”
Franz:” yes, the pair just discusses and finds out the best solution. In my
71
Grundlagen
group we have a fixed plan, one for about two hours.”
Interviewer:”Do you think it is necessary to purposely organize the pair this
way that one of the pair is more experienced than the other?”
Franz:”If your programmers are not at the same level, of course it’s better
to let the experienced one and a new one make a couple, and during the pair
programming time the new guy can learn something from the senior one and
then become more familiar with the development tools or languages. ”
Felix:”Ja, yes, in my opinion, people at the same level are even more easily
to have conflict with each other, ( laugh).”
Interviewer: ”I think that’s all, Thank you very much for the interview,
and at last can I ask you both to give a conclusion about Pair Programming,
just one or two sentence, not much.”
Felix:”Altogether, Pair Programming is efficient, just need to pay attention
to the cooperation of the pair.”
Franz:” carefully make the decision whether to execute Pair Programming,
some project is truly not for it, and make sure you have the right person. ”
Interviewer: ” again, thanks and wish this project be successful ”
4.3.3
The data Analysis
From the note I have took, and the interview recorded, I successfully got the
conclusion:
First of all, Pair Programming has many advantages like high efficiency, quick
reflection for changing condition, good learning classroom for inexperienced
programmers etc.
Secondly, it also has its own restrictions like long preparing time for pair
coordination, only proper for relatively small project, high demand for good
communication etc.
Thirdly, an experienced, high respectful, goal-oriented project manager is
very important for the execution of Pair Programming, relatively young group
of programmers who can easily accept new strategy is more fitful for Pair
Programming.
All in all, every project method has its advantages and disadvantages, no
method is all-can key for a successful project, use it properly and cautiously,
you can get happy ending.
72
5 Future work
4.4
Advantages and disadvantages of participant
observation
Participant observation is ideal for developing an understanding of how individuals respond to, interact with, and make use of various narual resources.
For the individuals being observed, their opinions and perceptions are their
reality. Understanding those perceptions can not only give the participants
self-reflection, but also provide the researchers with deep insight and perspective she or he may not otherwise gain. This information can then be further
used as resources for analysis. All in all, through Participant observation,
the researchers can from every aspect study the social problems or society
cultures and people’s ordinary life.
But there are still disadvantages of participant observation: firstly, The
researcher must devote a large amount of time (and money) to develop this
complex understanding. Secondly, an ethnographer’s objectivity may decline as he or she spends more time among the members. Thus,the researchers must be aware of bias and how this influences decisions related
to data recording, interpretation, and reporting. But probably the most serious and difficult problem is ”ethics”. C. George Boeree has once said in
his book:”Do you or do you not participate in activities that are illegal or
that you consider immoral or unethical? My own feeling is that you should
not present yourself to the people you are studying as something other than
yourself. You may get carried away and feel like you are becoming one of
them, but they rarely see you that way. Besides which, your goal is to learn
about them, not become them. So your moral and ethical obligations are
yours - and I believe that most groups will respect you for being yourself in
this regard. Whether or not you then engage in illegal activities depends on
your moral/ethical judgments and your willingness to risk legal punishment
in exchange for the trust of the people.”
5
Future work
Although qualitative research measurement has already been used for a long
time, and in various research fields, there is still much future work waiting
for the researcher’s attention.
Probably the most urgent is the validity of qualitative research. Guba and
Lincoln has proposed four criteria for judging the soundness of qualitative
research:
73
Grundlagen
Judging Quantitative Research
internal validity
external validity
reliability
objectivity
Judging Qualitative Research
credibility
transferability
dependability
confirmability
However, for these criteria, there are various voices speaking out, some
researchers argued:” these criteria are just re-labeling the very successful
quantitative criteria in order to accrue greater legitimacy for qualitative research.” Some researchers suggested:” the alternative criteria represent a
different philosophical perspective that is subjectivist rather than realist in
nature.”William M.K.Trochim(2002) ..... Still many and many different ideas
about the criteria presented out, and we believe new ideas and conceptions
will continuously appear in the future.
Then what will be the relatively good enough criteria to judge the validity and reliability of qualitative data? How to evaluate them in qualitative
research? As far as I know, at present no researchers or scholars have already
pointed out an effective method to assess the validity and reliability in qualitative research, and no criteria can be on the table without an amount of
anti-opinions, which, we all know, really need much future work.
6
Conclusion
Although qualitative method has been put into usage for a long time, many
people still can’t tell the exact meaning of it, in order to give a clear and complete view of qualitative method, after a short introduction of the definition
and history of qualitative method, a brief comparison between qualitative
and quantitative research methods, this paper has mainly represented one of
the most commonly used qualitative methods-participate observation. This
method has not only used in the area of social science, anthropology, medicine
but also in computer science and other engineering fields, hopefully in the
future, more and more research projects can make benefit of participate observation and find out some ways to overcome its shortcomings.
References
Florence R. Kluck-hohn The participant Observer Technique in Small Communities American Journal of
Sociology
Willian F. Whate Observational Field-Work Methods in
74
References
Research Methods in the Social Science
Arthur J. Vidich Participant Observation and The Collection and Interpretation of Data American Journal of
Sociology
Morris S. Schoartz Problems in Participant Obsevation
American Journal of Sociology
Patton, Michael Quinn (1980) Qualiatative Evaluation
Methods. Beverley Hills: Sage
Denzin Norman(1998) Introduction:Entering the Field of
Qualitative Research Thousand Oaks:Sage
Levi-Strauss Claude(1963)La
structuralisme.Paris:Esprit
pensée
sauvage
et
le
Beck Howard(1989)Studies in Symbolic Interaction10.
Tricks of the Trade
Holsti, O.R. (1969)Content Analysis for the Social Sciences and Humanities. Reading, MA: Addison-Wesley
Mayring,Phillip (2000)Qualitative
Forum:Qualitative Social Research
Content
Analysis
Krippendorff, K.(1980) Content Analysis: An Introduction
to Its Methodology. Newbury Park, CA: Sage.
Morris S. Schwartz (1955)Problems in Participant Observation The American Journal of Socialogy
Janet Cooper (2004) Using Participant or non-participant
observation to explain information behaviour Information
Research, Vol.9 No 4
Charles Soukup (2004) Multimedia Performance in a
Computer-Mediated Community:Communication as a
Virtual Drama JCMC 9 (4)
C. George Boeree Qualitative Method chapter 11 Shippensburg University
William M.K.Trochim (2002) Qualitative Validity Research Method Knowledge Base
75
Grundlagen
76
Hypothesen und T-Test
Alexander Becher
Keywords: Schätzen, Punktschätzer, Intervallschätzer, Konfidenzintervalle, Hypothesen, Nullhypothese, Alternativhypothese, Testen, α-Fehler, Signifikanz, βFehler, Teststärke, t-Test, Einstichprobenfall, Zweistichprobenfall
Abstract
Der t-Test ist ein statistischer Test zum Überprüfen von Unterschiedshypothesen. Er kann zum Vergleich von normalverteilten
Merkmalen, deren Varianz unbekannt ist, angewandt werden. Bei
nicht normalverteilten Merkmalen kann der t-Test bei großem Stichprobenumfang dennoch angewandt werden. Er ist somit für viele praktische Fragestellungen von Bedeutung.
Grundlagen
1
Einführung und Grundlagen
Die Organisation dieser Arbeit ist wie folgt:
Dieser Abschnitt widmet sich den notwendigen Grundlagen aus der Statistik. Er ist stellenweise absichtlich kurz gehalten, da Details in jedem einführenden Text zu Stochastik oder Statistik nachgeschlagen werden können. Die Darstellung von Schätzern und Konfidenzintervallen ist etwas ausführlicher gehalten, da ein Verständnis dieser Themen für die späteren Teile
wichtig ist.
Abschnitt 2 widmet sich ganz den verschiedenen Arten von Hypothesen. Er führt die zugehörigen Begriffe ein und erläutert die möglichen Formulierungen anhand von Beispielen.
Eine allgemeine Einführung in Tests findet sich im anschließenden Abschnitt 3. Die grundlegenden Eigenschaften und Voraussetzungen eines Tests
werden dort allgemein besprochen und die Probleme bei der praktischen Umsetzung umrissen.
Der t-Test bildet das Thema von Abschnitt 4. Seine verschiedenen
Arten, die dahintersteckenden Modelle sowie ihre Voraussetzungen werden
dargestellt sowie das praktische Vorgehen erläutert.
Der abschließende Abschnitt 5 führt alle Informationen aus den vorhergehenden Abschnitten in einem fiktiven Anwendungsbeispiel zusammen und
erlaubt einen Einblick in die praktische Anwendung dieser Konzepte.
Eine gut zu lesende, verständliche, mit Beispielen versehende und trotzdem theoretisch fundierte Darstellung des größten Teils des Stoffs findet
sich in [GB05], das eine der hauptsächlichen Quellen für diese Arbeit war.
Viele Gedanken zur praktischen Anwendung zusammen mit vielen Beispielen
finden sich in [Bor05]. Hilfreich waren außerdem die Artikel ”‘T-Test”’, ”‘Students t-Verteilung”’, ”‘Zufallsvariable”’, ”‘Schätzen und Testen”’ und ”‘Statistischer Test”’ aus Wikipedia sowie [Sch01].
1.1
Stichproben und Grundgesamtheiten
Mit dem Ausdruck Grundgesamtheit oder Population wird für ein stochastisches Modell (bzw. für einen statistischen Test) die Menge aller prinzipiell
untersuchbaren Objekte bezeichnet. Von der stochastischen Sichtweise aus
entspricht die Grundgesamtheit der Menge Ω des zugehörigen Wahrscheinlichkeitsraumes. Einige Beispiele:
• Für eine Untersuchung der Gehaltsstruktur eines Unternehmens ist
die Grundgesamtheit gleich der Menge der Personen, die sich auf der
Gehaltsliste dieses Unternehmens befinden.
78
1 Einführung und Grundlagen
• Soll die Wirksamkeit eines Medikaments oder einer medizinischen Behandlung untersucht werden, so setzt sich die Grundgesamtheit aus der
Menge aller Patienten zusammen.
• Steht die Wirksamkeit von Entwicklungsmethoden für Software auf
dem Prüfstand, so besteht die Grundgesamtheit aus allen Softwareprojekten.
Eine Zufallsvariable ordnet einem Element aus der Population eine reelle
Zahl1 zu. Andere Bezeichnungen für Zufallsvariablen sind Merkmal oder
Eigenschaft. Formal ist eine Zufallsvariable eine (meßbare) Funktion X :
Ω → R. Für ein Element ω der Grundgesamtheit bezeichnet somit X(ω)
den zugehörigen Wert der Zufallsvariable X. X(ω) stellt eine sogenannte
Realisation der Zufallsvariable X dar.
Beispiele für Zufallsvariablen:
• monatliches Gehalt einer Person in Euro;
• Behandlungsdauer oder -erfolg bei einem bestimmten Patient unter Anwendung einer bestimmten Behandlungsmethode;
• Entwicklungsdauer oder Anzahl der erfüllten Spezifikationsanforderungen bei einer Software, die mit einer bestimmten Methode entwickelt
wurde.
Zufallsvariablen haben eine zugehörige Wahrscheinlichkeitsverteilung P X
(mit P X (x) = P (X ≤ x)). Damit läßt sich der Erwartungswert einer Zufallsvariablen definieren2 :
X
EX =
x · P (X = x) .
(1)
x∈R
Auf ähnliche Weise wird die zu einer Zufallsvariablen gehörende Varianz
definiert:
X
Var X =
(x − E X)2 · P (X = x) .
(2)
x∈R
Eine Zufallsstichprobe kann man als eine Menge von stochastisch unabhängigen, identisch verteilten3 Zufallsvariablen X1 , . . . , Xn ansehen. Die
dazugehörigen Realisationen X1 (ω), . . . , Xn (ω) = x1 , . . . , xn bezeichnet man
1
allgemein: einen Vektor von reellen Zahlen
hier in der Variante für diskrete Zufallsvariablen
3
iid: independent, identically distributed
2
79
Grundlagen
dann als (konkrete) Stichprobe. Die Zahl n bezeichnet den Stichprobenumfang.
Zwei wichtige statistische Kennwerte einer Stichprobe, die im folgenden
noch benötigt werden, sind das sogenannte Stichprobenmittel
n
1X
X=
Xi
n i=1
(3)
und die Stichprobenvarianz
n
1 X
S =
(Xi − X)2 .
n − 1 i=1
2
1.2
(4)
Grundzüge des Schätzens
Beim Schätzen möchte man von den Eigenschaften einer Stichprobe auf
die Eigenschaften der Grundgesamtheit schließen. Die Grundgesamtheit ist
möglicherweise zu groß, um vollständig untersucht zu werden (z. B. die Tagesproduktion einer Fabrik), oder schlichtweg unbekannt (z. B. alle an einer
bestimmten Krankheit leidenden Personen). Daher untersucht man nur eine
endliche Teilmenge der Grundgesamtheit (die Stichprobe).
Das zu untersuchende Merkmal wird durch eine Zufallsvariable modelliert,
deren konkrete Verteilung zunächst unbekannt ist. Oft kann man von einer
Normalverteilung des Merkmals ausgehen oder eine andere Verteilungsform
theoretisch begründen, so daß nur noch die Parameter oder Kennwerte der
Verteilung ermittelt werden müssen. Für eine normalverteilte Zufallsvariable
X ∼ N (µ, σ 2 ) sind z. B. die interessanten Parameter µ ∈ R und σ 2 > 0. Die
Menge aller möglichen Parameter nennt man Parameterraum und bezeichnet
ihn mit Θ ⊂ Rm für m viele Parameter. Im Falle der Normalverteilung ist
also m = 2 und der gesuchte Parametervektor (µ, σ 2 ) = θ ∈ Θ = R × R+ .
Allgemein ist eine Schätzfunktion eine Funktion θ̂(X1 , . . . , Xn ) von n Zufallsvariablen. Das Ergebnis dieser Funktion ist eine neue Zufallsvariable
Xθ . Für jede konkrete Stichprobe kann man somit einen Schätzwert für den
Parametervektor θ berechnen.
Mittels der in (3) bzw. (4) definierten Werte für das Stichprobenmittel
X und die Stichprobenvarianz S 2 erhält man einen Schätzer (X, S 2 ) für die
Parameter einer normalverteilten Zufallsvariablen. Für zwei verschiedene
konkrete Stichproben werden sich im Regelfall zwei verschiedene geschätzte
Parameterwerte ergeben. Daher ist ein Schätzer wieder eine Zufallsvariable
und kein fester Wert.
Ist das Merkmal X nicht normalverteilt, so kann man dennoch seinen Erwartungswert E X und ihre Varianz Var X aus einer Stichprobe schätzen,
80
1 Einführung und Grundlagen
solange der Stichprobenumfang hinreichend groß ist. Eine der Folgerungen des Zentralen Grenzwertsatzes der Wahrscheinlichkeitsrechnung besagt,
daß Stichprobenmittel und -varianz sich mit wachsendem n immer mehr
normalverteilten Zufallsvariablen annähern. In der Praxis kann man diese
Näherung ab einem Stichprobenumfang von etwa n ≥ 30 voraussetzen.
Um verschiedene Schätzer miteinander zu vergleichen, definiert man
wünschenswerte Eigenschaften eines Schätzers. Die wichtigste ist die Erwartungstreue, die besagt, daß der Erwartungswert des Schätzers gleich dem
wahren Parametervektor θ ist. In Formeln:
Eθ [θ̂(X1 , . . . , Xn )] = θ
für alle θ ∈ Θ .
(5)
Wie man nachrechnen kann, sind das Stichprobenmittel X und die Stichprobenvarianz S 2 erwartungstreue Schätzer für die Parameter µ und σ 2
einer Normalverteilung, und für große Stichproben auch approximativ für
Erwartungswert E X und Varianz Var X einer beliebigen Zufallsvariablen
X. Die Verteilung der Zufallsvariablen X und S 2 nennt man auch Stichprobenkennwerteverteilung.
Betrachten wir schließlich noch die Frage, wie stark die erwartete Abweichung des geschätzten Mittelwerts vom tatsächlichen Mittelwert ist. Der
Standardfehler des Mittelwerts σX bezeichnet die mittlere quadratische Abweichung des geschätzten Mittelwerts vom tatsächlichen Mittelwert, also die
Standardabweichung der Zufallsvariable X:
q p
σX = Var X = E (X − µ)2
r
σ2
σ
=
=√ ,
n
n
(6a)
wobei sich die zweite Zeile durch Einsetzen der Definition von X ergibt
und σ 2 = Var X die Populationsvarianz bezeichnet. Die Populationsvarianz
kann man, wenn sie unbekannt ist, aus den empirischen Daten mit Hilfe des
Schätzers S 2 schätzen und erhält so folgende Gleichung für den geschätzten
Standardfehler des Mittelwerts σ̂X :
r
S2
σ̂X =
.
(6b)
n
1.3
Konfidenzintervalle
Der vorige Abschnitt hat sogenannte Punktschätzer eingeführt. Diese berechnen aus einer Stichprobe einen einzelnen Wert. Ein anderer Ansatz besteht
81
Grundlagen
darin, von einer Stichprobe ausgehend ein ganzes Intervall von Werten
anzugeben, so daß dieses Intervall mit hoher Wahrscheinlichkeit den wahren
Wert des Parameters überdeckt. Ein solches Intervall nennt man Konfidenzintervall, einen solchen Schätzer einen Intervallschätzer.
Für eine Stichprobe X1 , . . . , Xn besteht ein Intervallschätzer
K(X1 , . . . , Xn ) für den Parameter θ allgemein aus einer unteren Grenze
θ(X1 , . . . , Xn ) und einer oberen Grenze θ(X1 , . . . , Xn ). Man nennt K = (θ, θ)
einen Intervallschätzer zum Niveau 1 − α, falls
Pθ [θ(X1 , . . . , Xn ) ≤ θ ≤ θ(X1 , . . . , Xn )] ≥ 1 − α
für alle θ ∈ Θ ,
(7)
also die Wahrscheinlichkeit, daß das berechnete Konfidenzintervall den tatsächlichen Parameter überdeckt, mindestens 1 − α beträgt. Intervallschätzer
sind wie schon Punktschätzer selbst wieder Zufallsvariablen. Bezeichnet man
etwas ungenau das berechnete Konfidenzintervall mit K, so läßt sich die Bedingung (7) auch als Pθ (K 63 θ) ≤ α schreiben. Ein solches Intervall bezeichnet man auch als (1 − α)-Konfidenzintervall.
Als Ausgangsbasis für die Konstruktion eines Intervallschätzers dient
im Regelfall ein Punktschätzer. Beispielsweise ergibt sich für n viele normalverteilte Stichprobenvariablen X1 , . . . , Xn ∼ N (µ, σ 2 ) der Punktschätzer
X mit Erwartungswert E X = µ und Standardabweichung σX = √σn . Ist die
Varianz von X bekannt, so kann man hieraus die standardisierte Zufallsvariable Z = X−µ
∼ N (0, 1) bilden.
σX
Zur Bestimmung des Konfidenzintervalls bedient man sich des α-Quantils
der Standardnormalverteilung, das wie folgt definiert ist: zα∗ ist der kleinste
Wert mit P (Z ≤ zα∗ ) = α. Aus dieser Bedingung erhält man durch Umformen
und Einsetzen der Definition von Z die folgenden (1 − α)-Konfidenzintervalle
(KI) für den Erwartungswert einer Normalverteilung bei bekannter Varianz:
∗
−∞, X + z1−α
· σX
unteres KI,
∗
X − z1−α
· σX , ∞
oberes KI,
i
h
∗
∗
α · σ , X + z
X − z1−
zweiseitiges KI.
1− α · σX
X
2
2
Ist die Varianz σ von X nicht bekannt, so ist auch der Wert von σX = √σn
nicht bekannt. In diesem Fall kann man versuchen, σ aus den Daten der
Stichprobe mittels (6b) zu schätzen. In diesem Fall bildet man aus X die
neue Zufallsvariable T = X−µ
. Diese ist jedoch nicht mehr exakt standardσ̂X
normalverteilt, sondern folgt der t-Verteilung mit (n − 1) Freiheitsgraden:
T ∼ tn−1 . Folglich benutzt man bei der Herleitung der Konfidenzintervalle nicht mehr das α-Quantil der Standardnormalverteilung zα∗ , sondern
82
2 Hypothesen
das analog definierte α-Quantil der t-Verteilung t∗n−1;α . Man erhält dann
die folgenden (1 − α)-Konfidenzintervalle (KI) für den Erwartungswert einer
Normalverteilung bei unbekannter Varianz:
−∞, X + t∗n−1;1−α · σ̂X
unteres KI,
∗
X − tn−1;1−α · σ̂X , ∞
oberes KI,
i
h
zweiseitiges KI.
X − t∗n−1;1− α · σ̂X , X + t∗n−1;1− α · σ̂X
2
2
2
Hypothesen
Als Hypothese bezeichnet man allgemein ”‘eine vorläufig durch Beobachtungen oder Überlegungen begründete Annahme oder Vermutung, die zur Erklärung bestimmter Phänomene dient”’ (aus Wikipedia). In der stochastischen Sichtweise ist eine Hypothese eine Vermutung ”‘über die Beschaffenheit
der unbekannten Verteilungsfunktion der Stichprobenvariablen X1 , . . . , Xn ”’
(aus [Sch01]).
Man leitet also z. B. aus einer Theorie verschiedene Aussagen ab, die
nach dieser Theorie als gültig angesehen werden müssen. Diese Vermutungen
möchte man anschließend durch Experimente oder durch statistische Studien
entweder bestätigen oder widerlegen. Beispiele:
• Die Newtonsche Mechanik sagt voraus, daß die Lichtgeschwindigkeit in
zwei relativ zueinander bewegten Bezugssystemen unterschiedlich ist.
Diese Hypothese wurde durch Experimente sehr genau widerlegt.
• Die allgemeine Relativitätstheorie sagt die Ablenkung von Licht in
einem Gravitationsfeld nach einer bestimmten Formel voraus. Diese
Hypothese wurde durch astronomische Messungen bestätigt.
• Ein Hersteller eines Medikaments behauptet, sein Mittel wirke besser
als andere gegen eine bestimmte Krankheit. In einem Doppelblindtest
wird die Gültigkeit dieser Behauptung untersucht.
• Es wird vermutet, daß die Entwicklungszeit einer Software mit der Anzahl der an ihr beteiligten Entwickler wächst.
Die Entscheidung, ob eine Hypothese anzunehmen oder zu verwerfen
ist, geschieht durch Ziehen einer Stichprobe, deren Ergebnisse mit vorher
definierten Schwellenwerten verglichen werden (siehe Abschnitte 3 und 4).
Diesen Vorgang nennt man einen (statistischen) Test.
83
Grundlagen
Man unterscheidet Hypothesen in Unterschieds- und Zusammenhangshypothesen. Eine Unterschiedshypothese liegt vor, falls lediglich ein Unterschied zwischen zwei Merkmalen vermutet wird. Dies ist z. B. in der Behauptung über die Medikamentenwirksamkeit der Fall: Modelliert man die
Wirksamkeit als die Heilungswahrscheinlichkeit, so ist die Aussage, daß diese
für das neue Medikament größer ist als für andere. Hingegen wird bei der
Aussage über die Software-Entwicklungsdauer ein Zusammenhang zwischen
dieser und der Entwicklerzahl behauptet. Eine Zusammenhangshypothese
trifft also eine Aussage über eine Abhängigkeit zweier Merkmale voneinander.
Die Art der Hypothese bestimmt die Art des statistischen Tests zu ihrer
Überprüfung. Beispiele für Verfahren zur Überprüfung von Unterschiedshypothesen sind t-, F-, U- und Wilcoxon-Test. Mögliche Verfahren für Zusammenhangshypothesen sind Regressions- und Korrelationsrechnung.
2.1
Alternativ- und Nullhypothese
Die Hypothese, deren Gültigkeit behauptet wird, bezeichnet man als die
Alternativhypothese. Dieser Name rührt daher, daß die Gültigkeit dieser Hypothese nach dem jeweils aktuellen Kenntnisstand nicht allgemein akzeptiert
ist und sich erst durch einen statistischen Test beweisen muß. Die beiden
o. a. Beispiele über die Wirksamkeit eines Medikaments und die Entwicklungsdauer von Software sind typische Alternativhypothesen. Alternativhypothesen werden i. a. mit H1 bezeichnet.
Zu jeder Alternativhypothese läßt sich die gegenteilige Aussage formulieren, die z. B. für eine Unterschiedshypothese besagt, daß in Wirklichkeit
eben kein Unterschied existiert, oder für eine Zusammenhangshypothese,
daß es keinen Zusammenhang gibt oder dieser anders beschaffen ist als behauptet. Diese gegenteilige Hypothese wird Nullhypothese genannt und mit
H0 bezeichnet. Nullhypothesen werden als gültig erachtet, bis sie durch einen
statistischen Test widerlegt werden können. In den obigen Beispielen wären
die Nullhypothesen, daß ein neues Medikament keine besseren Chancen auf
Heilung bietet als bisherige Medikamente bzw. daß die Entwicklungsdauer
nicht mit der Entwicklerzahl wächst.
Oftmals ist es schwierig, eine umgangssprachlich formulierte Hypothese
in ein stochastisches Modell zu übertragen und sie als mathematische Hypothese zu formulieren. Möglicherweise existieren auch mehrere unterschiedliche mathematische Formulierungen mit der gleichen Aussage wie die
umgangssprachlich formulierte Hypothese. In vielen Fällen ist die präzise und
korrekte Formulierung einer mathematischen Hypothese eine der schwierigsten Aufgaben für die empirische Forschung.
84
2 Hypothesen
Auf die Frage, welche der beiden Hypothesen als Null- und welche als Alternativhypothese zu wählen ist, wird Abschnitt 3.6 noch genauer eingehen.
Typischerweise wird für die Hypothesenformulierung eine bestimmte
Verteilungsform des zugrundeliegenden Merkmals angenommen.
Die
Alternativ- und die Nullhypothese treffen dann Aussagen über einen oder
mehrere Parameter dieser Verteilung. Als Beispiel sei eine Stichprobe mit n
vielen iid Zufallsvariablen X1 , . . . , Xn ∼ N (µ, σ 2 ) gegeben. Die Behauptung
sei, daß der Parameter µ dieser Verteilung sich von einem bestimmten Wert
µ0 unterscheidet. Die Hypothesen lauten dann:
H 0 : µ = µ0
H1 : µ 6= µ0
Nullhypothese
Alternativhypothese
In einem anderen Fall läßt sich vielleicht behaupten, daß Patienten
mit einer bestimmten Vorgeschichte auf eine bestimmte Behandlung besser
ansprechen als andere. Um diese Behauptung zu überprüfen, würden zwei
Gruppen von Patienten in einer Studie untersucht: Gruppe 1 mit Patienten mit einer derartigen Krankheitsgeschichte, Gruppe 2 mit Patienten ohne
diese. Der Behandlungserfolg in Gruppe i sei mit µi bezeichnet. Es ergeben
sich als Hypothesen:
H 0 : µ1 ≤ µ2
H 1 : µ1 > µ 2
Nullhypothese
Alternativhypothese
Hypothesen werden nach mehreren Kriterien unterteilt. Eine Hypothese
wird einfache Hypothese genannt, falls sie von der Form µ = µ0 ist, also nur
durch einen einzelnen Wert des Parameters µ erfüllt werden kann, nämlich
durch den Wert µ0 . Hingegen umfaßt eine zusammengesetzte Hypothese
mehrere mögliche Werte für den Parameter. So wird z. B. eine Hypothese
der Form µ < µ0 durch alle Verteilungen mit einem Parameter µ erfüllt, der
unter dem festen Wert µ0 liegt.
Die obigen Beispiele zeigen, daß eine Theorie es oft erlaubt, eine Hypothese mehr oder weniger genau zu formulieren. Es wird sich (in Abschnitt
3) herausstellen, daß die Durchführung eines statistischen Tests zur Überprüfung einer Hypothese umso leichter ist, je detaillierter sie formuliert wird.
Dabei bedeutet ”‘leichter”’, daß eine kleinere Stichprobengröße ausreichend
ist. Im folgenden werden die verschiedenen Möglichkeiten, Hypothesen zu
formulieren, besprochen und an Beispielen illustriert.
2.2
Gerichtete und ungerichtete Hypothesen
Eine Alternativhypothese der Form H1 : µ 6= µ0 wie im obigen Beispiel bezeichnet man als eine ungerichtete Hypothese. Es wird lediglich behauptet, daß
85
Grundlagen
irgendein wie auch immer gearteter Unterschied vorliegt. Über die Richtung
dieses Unterschieds wird jedoch keine Aussage getroffen.
Im Gegensatz dazu sagt die Alternativhypothese aus dem zweiten Beispiel
voraus, daß die neue Behandlungsmethode besser wirke, die Wirksamkeit also
größer sei als die bisheriger Medikamente. Ebenso wie im ersten Fall wird
ein Unterschied behauptet, jedoch ist hier klar, in welche Richtung dieser
Unterschied gehen soll. Derartige Hypothesen werden daher als gerichtete
Hypothesen bezeichnet.
Wenn θ den Parameter bezeichnet, über den eine Aussage getroffen werden soll, und θ0 ∈ Θ ein fester Wert ist, so ergeben sich je nach Art der
Alternativhypothese die folgenden möglichen Testprobleme:
H0 : θ = θ0 H1 : θ 6= θ0 zweiseitiger Test
H0 : θ ≤ θ0 H1 : θ > θ0 rechtsseitiger Test
H0 : θ ≥ θ0 H1 : θ < θ0 linksseitiger Test
(8)
(9)
(10)
Hierbei liegt dem zweiseitigen Test eine ungerichtete Alternativhypothese
zugrunde, wohingegen rechts- und linksseitiger Test eine gerichtete Alternativhypothese voraussetzen.
Beispiel für einen zweiseitigen Test. Ein Getränkehersteller möchte wissen, ob die von ihm eingesetzte Abfüllmaschine tatsächlich im Mittel die
eingestellte Füllmenge µ0 liefert. Liefert die Maschine eine zu hohe Füllmenge, so verliert der Hersteller Geld, da er mehr Ware verkauft als er abrechnet. Ist die Füllmenge dagegen zu niedrig, so muß der Hersteller mit Verbraucherbeschwerden rechnen. Die Verteilung der Füllmengen kann als Normalverteilung angenommen werden. Die Nullhypothese lautet H0 : µ = µ0 ,
die Alternativhypothese H1 : µ 6= µ0 .
Beispiel für einen linksseitigen Test. Ein Verbraucher möchte wissen, ob
in den von ihm gekauften Getränkeflaschen eventuell weniger Inhalt ist als
auf der Verpackung angegeben und somit vielleicht Grund zur Reklamation
besteht. Wenn der tatsächliche Inhalt größer ist als der angegebene Inhalt,
so wäre dies dem Verbraucher recht. Daher lautet die Nullhypothese H0 :
µ ≥ µ0 , und die Alternativhypothese H1 : µ < µ0 .
Beispiel für einen rechtsseitigen Test. Ein externer Berater wird vom
Getränkehersteller mit einer Optimierung seiner Geschäftsprozesse beauftragt. Der Berater möchte herausfinden, ob der Hersteller Geld verliert, weil
die Füllmenge der Getränkeflaschen zu hoch ist. Ist sie zu niedrig, so ist dies
86
3 Tests und Fehler
für den Berater kein Problem. Die Nullhypothese ist also H0 : µ ≤ µ0 , die
Alternativhypothese H0 : µ > µ0 .
Auch bei Zusammenhangshypothesen kann man zwischen gerichteten und
ungerichteten Hypothesen unterscheiden. Eine ungerichtete Zusammenhangshypothese würde aussagen, daß zwischen zwei Merkmalen ein irgendwie gearteter Zusammenhang besteht, ohne diesen festzulegen. Beispielhypothese: ”‘Anzahl der eingesetzten EDV-Systeme in einer Verwaltung und
ihre Effizienz sind miteinander gekoppelt.”’ Eine gerichtete Hypothese hingegen würde die Richtung des Zusammenhangs festlegen, also z. B. behaupten,
daß Merkmal A wächst, wenn Merkmal B sinkt. Beispielhypothese: ”‘Die
durchschnittlichen Strom- und Heizkosten eines Monats steigen mit abnehmender Durchschnittstemperatur.”’
2.3
Spezifische und unspezifische Hypothesen
Während eine gerichtete Unterschiedshypothese lediglich einen Unterschied
in einer bestimmten Richtung fordert, legt eine spezifische Hypothese zusätzlich den Betrag fest, den dieser Unterschied mindestens haben soll. Analog
drückt eine spezifische Zusammenhangshypothese den vermuteten Zusammenhang mit konkreten (oberen oder unteren) Grenzen für den Korrelationskoeffizienten aus. Es wird also beispielsweise behauptet, jeder zusätzliche
Entwickler verlängere die Entwicklungszeit eines Programms um den Faktor 0,8, oder die Erfolgsquote des neuen Medikaments sei um mindestens 4
Prozentpunkte besser als die bisher benutzten.
Je spezifischer sich eine Hypothese formulieren läßt, desto leichter wird
wiederum ihre empirische Überprüfung. Kann die Theorie nur einen Unterschied oder einen Zusammenhang begründen, ihn aber nicht quantifizieren,
so muß man auf unspezifische Hypothesen zurückgreifen.
3
Tests und Fehler
Wenn die theoretischen hergeleiteten Aussagen in mathematische Hypothesen umgesetzt worden sind, kann man die empirische Überprüfung mittels
eines Tests angehen. Dazu wird eine Stichprobe gezogen und das Ergebnis mit vorher festgelegten Bereichen verglichen, in denen die Alternativhypothese entweder akzeptiert oder verworfen wird. Die Menge aller möglichen
Stichprobenergebnisse (der Stichprobenraum) wird also partitioniert in zwei
Mengen K und K{ . Die Menge K ist der Ablehnungsbereich der Nullhypothese und wird als kritischer Bereich des Tests bezeichnet. Die NullhyMethoden der empirischen Softwaretechnik
87
Grundlagen
pothese wird also verworfen, falls die konkrete Stichprobe x1 , . . . , xn in den
kritischen Bereich K fällt.
Sind die Hypothesen bezüglich eines Parameters θ formuliert, so erhält
man die Aufteilung des Stichprobenraums aus einer Aufteilung des Parameterraums Θ in zwei Teilmengen Θ0 und Θ1 , die der Nullhypothese H0 : θ ∈ Θ0
bzw. der Alternativhypothese H1 : θ ∈ Θ1 entsprechen und somit direkt aus
diesen abgelesen werden können.
In der Praxis geschieht die Überprüfung, ob eine Stichprobe in den kritischen Bereich fällt oder nicht, mittels einer aus der Stichprobe berechneten
reellwertigen Zufallsvariablen, der sogenannten Prüfgröße oder Teststatistik. Ein Beispiel für eine Prüfgröße ist das Stichprobenmittel X. Der kritische Bereich ist dann als Intervall (k ∗ , ∞), (−∞, k ∗ ) oder [−k ∗ , k ∗ ]{ =
(−∞, −k ∗ ) ∪ (k ∗ , ∞) gegeben. Die Zahl k ∗ heißt kritischer Wert. Die
Entscheidung fällt durch Vergleich des konkreten Wertes der Teststatistik mit
dem kritischen Wert Ist z. B. der beobachtete Wert der Teststatistik kleiner
als der kritische Wert, so wird die Nullhypothese bei einem rechtsseitigen
Test beibehalten und bei einem linksseitigen Test verworfen.
Da jede Stichprobe auf dem Zufall beruht, besteht die Möglichkeit, daß
ein Test eine falsche Entscheidung trifft: Die Nullhypothese könnte verworfen werden, obwohl sie in Wirklichkeit zutrifft. Es könnte auch sein, daß
eine in Wirklichkeit geltende Alternativhypothese nicht als richtig erkannt
wird. Ein guter Test sollte natürlich derartige Fehler nur mit einer geringen Wahrscheinlichkeit begehen. Die Wahl von akzeptablen Grenzen für
diese Fehlerwahrscheinlichkeiten muß vor der Durchführung der Stichprobe
geschehen und bestimmt den kritischen Bereich K des Tests.
3.1
α-Fehler (Fehler 1. Art)
Als Fehler 1. Art oder α-Fehler wird die Ablehnung einer in Wirklichkeit
zutreffenden Nullhypothese durch einen Test bezeichnet. Die Wahrscheinlichkeit, einen solchen α-Fehler zu begehen, heißt Irrtumswahrscheinlichkeit.
Der Irrtum, der dabei begangen wird, besteht demnach in der Verwerfung
der Nullhypothese, obwohl diese richtig ist.
Die Grundlage für eine Entscheidung des Tests gegen die Nullhypothese
sind die Werte der konkreten Stichprobe. Die Irrtumswahrscheinlichkeit ist
die Wahrscheinlichkeit, daß das Ergebnis der Stichprobe x1 , . . . , xn im kritischen Bereich K liegt, obwohl die tatsächliche Verteilung des Merkmals
mit der Nullhypothese im Einklang ist. Für eine einfache Nullhypothese
der Form H0 : θ = θ0 ergibt sich die Irrtumswahrscheinlichkeit direkt zu
Pθ ((X1 , . . . , Xn ) ∈ K), wobei Pθ die Verteilungsfunktion einer mit Parameter
θ verteilten Zufallsvariable bezeichnet.
88
3 Tests und Fehler
Im Falle einer zusammengesetzten Nullhypothese H0 : θ ∈ Θ0 gibt es für
jeden möglichen Wert des Parameters θ eine andere Verteilung des Merkmals.
Somit ergeben sich auch mehrere Werte für die Irrtumswahrscheinlichkeit,
jeweils in Abhängigkeit vom tatsächlichen Wert des Parameters.
3.2
Statistische Signifikanz
Ein Test, dessen Irrtumswahrscheinlichkeit (also die Wahrscheinlichkeit für
einen Fehler 1. Art) klein ist, wird signifikant genannt. Die Signifikanz ist
eine der wichtigsten Eigenschaften eines Tests, da sie eine obere Schranke
für die Irrtumswahrscheinlichkeit angibt. Formal sagt man, ein Test ist signifikant zum Niveau α, wenn gilt
Pθ ((X1 , . . . , Xn ) ∈ K) ≤ α
für alle θ ∈ Θ0 ,
(11)
d. h. die Wahrscheinlichkeit, daß der Test sich bei gültiger Nullhypothese
H0 : θ ∈ Θ0 gegen diese entscheidet (Pθ ((X1 , . . . , Xn ) ∈ K)), ist höchstens α.
Das kleinste solche α ∈ [0, 1] heißt Signifikanzniveau des Tests.
In der praktischen empirischen Forschung werden üblicherweise Tests mit
Signifikanzniveau α = 5 % oder α = 1 % benutzt. Die Ergebnisse derartiger
Tests werden als (statistisch) signifikant bzw. sehr signifikant bezeichnet.
Man beachte, daß das Signifikanzniveau eine Eigenschaft des Tests ist,
und nicht von der konkreten Stichprobe abhängt. Es muß daher vor Durchführung der Stichprobe festgelegt werden, welches Signifikanzniveau für die
zu untersuchenden Hypothesen angebracht ist. Ein kleines Signifikanzniveau
bedeutet ein kleines Risiko, die Nullhypothese abzulehnen, obwohl sie in
Wirklichkeit zutrifft. Je nach den Konsequenzen dieser Entscheidung ist α
entsprechend zu wählen. Eine fortführende Diskussion mit Beispielen findet
sich in Abschnitt 3.6.
3.3
Effektgrößen
Mit wachsendem Stichprobenumfang wird es immer ”‘leichter”’, eine Alternativhypothese auf einem beliebig kleinen Signifikanzniveau abzusichern. Das
heißt, wenn man die Stichprobe nur beliebig groß macht, erhält man immer ein Ergebnis, bei dem die Nullhypothese zu verwerfen ist, selbst wenn
die Abweichung von der Hypothesenbehauptung sehr klein ist. Der Grund
dafür ist die Abnahme der Stichprobenvarianz σX = √σn mit wachsendem
Stichprobenumfang n.
Je nachdem, welche Konsequenzen die Ablehnung der Nullhypothese mit
sich bringt, ist der entstehende Aufwand aber eventuell nicht für beliebig
89
Grundlagen
kleine Effekte gerechtfertigt, sondern erst ab einer bestimmten Größe des Effekts. Mit Effekt wird hierbei die Größe der Abweichung des tatsächlichen
Parameters von dem Wertebereich der Nullhypothese bezeichnet. Eine spezifische Hypothese ist ein gutes Beispiel für eine Behauptung, die die Größe
des postulierten Effekts spezifiziert.
Eine Effektgröße läßt sich prinzipiell für fast jeden praktisch relevanten
Test definieren. Im Falle von Unterschiedshypothesen handelt es sich dabei
z. B. um die Differenz zwischen zwei verschiedenen Stichproben, relativiert
an der Varianz der zugrundeliegenden Zufallsvariablen. Diese Definition der
Effektgröße dient der Vergleichbarkeit verschiedener Studien untereinander.
Bei einer Effektgröße von = 0,2 spricht man von einem schwachen, bei
= 0,5 von einem mittleren und bei = 0,8 von einem starken Effekt.
Die Festlegung einer Effektgröße vor Bestimmung eines Tests erlaubt es,
den Stichprobenumfang passend zu dimensionieren, um unnötigen Aufwand
zu vermeiden und dennoch verwertbare Ergebnisse zu erhalten. Sie erfordert
allerdings eine sehr genaue Kenntnis der vermuteten Zusammenhänge, aus
denen sich die vermutete Größe des Effekts ergeben soll.
3.4
β-Fehler (Fehler 2. Art)
Die andere Art von Fehler, neben einem α-Fehler, die ein Test begehen kann,
besteht darin, eine in Wirklichkeit zutreffende Alternativhypothese zu verwerfen. Dies entspricht der Situation, daß die Theorie stimmt, dies aber
aufgrund der Zufälligkeit des Stichprobenergebnisses nicht erkannt wird. Als
Konsequenz wird die vermutete Aussage für falsch erachtet und weiterhin die
Gültigkeit der Nullhypothese angenommen.
Derartige Fehler werden als Fehler 2. Art oder als β-Fehler bezeichnet.
Die Wahrscheinlichkeit für ihr Auftreten hängt wie die Wahrscheinlichkeit für
α-Fehler vom wahren Wert des gesuchten Parameters θ ab. Der Test wird
sich gegen die Alternativhypothese entscheiden, falls das Ergebnis der Stichprobe außerhalb seines kritischen Bereichs liegt, also falls x1 , . . . , xn 6∈ K
gilt. Ist θ ∈ Θ1 der wahre Parameterwert (d. h. die Alternativhypothese
trifft zu), dann beträgt die Wahrscheinlichkeit für einen Fehler 2. Art
β(θ) = Pθ (X1 , . . . , Xn 6∈ K) (d. h. die Alternativhypothese wird vom Test
verworfen).
Im Gegensatz zu Fehlern 1. Art werden Fehler 2. Art nicht durch
eine obere Schranke für ihre Wahrscheinlichkeit kontrolliert. Bei der
Auswahl eines für die konkrete Fragestellung geeigneten Testverfahrens
wird lediglich eine Grenze für α-Fehler vorgegeben. Aus allen Tests, die
diese Bedingung erfüllen, wird dann derjenige mit der passendsten βFehlerwahrscheinlichkeit ausgewählt. Es ist jedoch nicht vorhersagbar, wie
90
3 Tests und Fehler
klein die β-Fehlerwahrscheinlichkeit letztendlich wird.
Für weitere Details sei auf Abschnitt 3.6 verwiesen.
3.5
Teststärke
Die Teststärke eines Tests ist eng mit der β-Fehlerwahrscheinlichkeit verwandt. Sie ist definiert als 1 − β(θ) für alle θ ∈ Θ. Andere Bezeichnungen
sind Güte, Macht, Power oder Trennschärfe. Man beachte, daß die Güte für
θ ∈ Θ0 der α-Feh”-ler”-wahr”-schein”-lich”-keit entspricht. Für θ ∈ Θ1 ergibt
sich hingegen 1 − β(θ) = 1 − Pr{Fehler 2. Art}.
Anschaulich bedeutet eine große Güte, daß der Test mit hoher
Wahrscheinlichkeit die Nullhypothese verwerfen wird, falls die Alternativhypothese zutrifft. Dies läßt sich auch direkt aus der Definition ablesen: Falls
die Alternativhypothese zutrifft, entspricht die Güte der Wahrscheinlichkeit,
keinen Fehler 2. Art zu begehen.
Die Teststärke wird von verschiedenen anderen Größen beeinflußt: Sie
nimmt zu mit wachsendem Signifikanzniveau α, mit wachsender Effektgröße
und mit wachsendem Stichprobenumfang n. Sie sinkt mit wachsender Varianz der Stichprobenvariablen. Außerdem hat ein einseitiger Test eine höhere
Teststärke als ein zweiseitiger Test.
3.6
Festlegen von Testanforderungen
Bei der Untersuchung einer Fragestellung auf ihre Richtigkeit hin gibt es viele
Möglichkeiten, die Hypothesen und Parameter eines Tests zu wählen. Dieser
Abschnitt beschäftigt sich mit der Auswahl der richtigen Möglichkeiten unter
praktischen Gesichtspunkten.
Es wurde bereits erwähnt, daß diejenige der beiden Hypothesen als Nullhypothese gewählt werden sollte, deren fälschliche Ablehnung die gravierenderen Konsequenzen nach sich zieht. Dies liegt daran, daß die Wahrscheinlichkeit für einen solchen Fehler 1. Art durch ein vorgegebenes Signifikanzniveau α beliebig klein gehalten werden können. So wird man bei
Fragestellungen, die bei falscher Beantwortung zu einem Risiko für Leib und
Leben von Menschen führen können (z. B. in der Medizin, bei der Personenbeförderung oder im militärischen Bereich), ein wesentlich kleineres Signifikanzniveau wählen als bei Fragestellungen, deren falsche Beantwortung
lediglich zu einer peinlichen Situation führen könnte (z. B. ein Verbraucher,
der ein Produkt zu Unrecht reklamiert).
Die typischen Werte α = 0,05 und α = 0,01 wurden bereits erwähnt. Für
die oben angesprochenen sensiblen Tests kommen allerdings durchaus auch
niedrigere Signifikanzniveaus wie α = 0,001 in Betracht.
91
Grundlagen
Weiterhin ist es erwähnenswert, daß die Werte für das α- und βFehlerniveau voneinander abhängen, so daß nicht beide gleichzeitig verringert
werden können, außer durch Vergrößerung des Stichprobenumfangs. Ein
Test mit kleinem α hat eine höhere β-Fehlerwahrscheinlichkeit (und damit
eine geringere Teststärke) als ein ähnlicher Test mit größerem α und gleicher
Stichprobengröße.
Kann man die Nullhypothese nun mit dem Wissen ablehnen, dabei nur
sehr unwahrscheinlich einen Fehler zu begehen, bleibt die Frage, ob die Alternativhypothese damit auch akzeptiert werden kann. Für unspezifische
Hypothesen ist diese Frage natürlich sofort zu bejahen. Bei spezifischen
Hypothesen sieht es jedoch anders aus. Der zu testende Parameter liegt
vielleicht in Wirklichkeit zwar innerhalb des kritischen Bereichs, in dem die
Nullhypothese abzulehnen ist; aber er könnte dennoch außerhalb des Bereichs liegen, in dem die spezifische Alternativhypothese als gültig anzuerkennen ist. Ebenso ist es denkbar, daß das Ergebnis einer Stichprobe weder die
Ablehnung von H0 noch die von H1 zuläßt.
Man kann zeigen, daß zwischen den Größen α, β, und n ein Zusammenhang besteht, der es erlaubt, bei gegebenem α, β und (deren Werte
aus inhaltlichen Überlegungen festgelegt oder gefolgert wurden) den Stichprobenumfang derart zu berechnen, daß solche Indifferenzbereiche gerade
vermieden werden.
Schließlich ist noch zu untersuchen, wie ob die Beweiskraft einer
Studie für die Akzeptanz der Alternativhypothese ausreicht.
Ein
weitverbreiteter Vorschlag besagt, um als akzeptabler Beleg für die Alternativhypothese gewertet werden zu können, müsse ein Testergebnis eine β-Fehlerwahrscheinlichkeit von wenigstens viermal der αFehlerwahrscheinlichkeit haben.
Es sei noch einmal darauf hingewiesen, daß diese Parameter Eigenschaften
des Tests darstellen und nicht im nachhinein aus einer bereits vorhandenen
Stichprobe berechnet werden sollten.
3.7
Herleitung eines Tests aus einem Intervallschätzer
Als Basis für die Bestimmung des kritischen Bereichs eines Tests
kann ein Intervallschätzer für den interessierenden Parameter θ dienen.
Für ein vorgegebenes Signifikanzniveau α berechnet man ein (1 − α)Konfidenzintervall für θ, wobei für einen zweiseitigen Test ein zweiseitiges
Konfidenzintervall, für einen linksseitigen Test ein unteres Konfidenzintervall und für einen rechtsseitigen Test ein oberes Konfidenzintervall gewählt
wird. Einsetzen des gesuchten Parameters θ und Umformen ergibt dann
den gewünschten kritischen Wert, wie im nachfolgenden Beispiel verdeutlicht
92
4 t-Test
wird.
Angenommen, der Mittelwert eines normalverteilten Merkmals mit
bekannter Varianz soll einem rechtsseitigen Test auf Niveau α mit H1 : µ > µ0
unterzogen werden. Die Signifikanzbedingung lautet:
Pµ ((X1 , . . . , Xn ) ∈ K) ≤ α
für alle µ ≤ µ0 ,
und das zugehörige (obere) Konfidenzintervall für den Mittelwert ist
σ
∗
K = K(X1 , . . . , Xn ) = X − z1−α · √ , ∞ ,
n
wobei
Pµ (µ 6∈ K) ≤ α
für alle µ ≤ µ0 .
Einsetzen von K liefert:
σ
∗
Pµ (µ < X − z1−α
·√ )
n
√ X −µ
∗
= Pµ ( n ·
> z1−α
)
σ
≤ α .
√
∗
Es liegt also nahe, Z = n · X−µ
als kritisals Teststatistik und z1−α
σ
chen Wert zu wählen, mit dem sich daraus ergebenden kritischen Bereich
∗
, ∞), in dem die Nullhypothese verworfen wird. Da der Mittelwert
K = (z1−α
µ jedoch nicht bekannt ist, setzt man die Grenze µ0 zwischen Nullhypothese
√
0
und Alternativhypothese stattdessen ein, und erhält Z = n · X−µ
als Testσ
statistik. Wie man sich leicht überzeugt, ist damit die Signifikanzbedingung
immer noch für alle µ ≤ µ0 erfüllt.
Analog ergeben sich die kritischen Bereiche K = (−∞, zα∗ ) für einen links∗
∗
seitigen und K = (−∞, −z1−
α ) ∪ (z
1− α , ∞) für einen zweiseitigen Test.
2
4
2
t-Test
In vielen praktisch interessanten Anwendungsfällen ist nur wenig über die
tatsächliche Verteilung des Merkmals bekannt. Vielfach ist zwar die Annahme einer Normalverteilung begründet, aber die Varianz der Verteilung
ist unbekannt. Ist dies der Fall, so liegt die Idee nahe, die Varianz ebenso
wie den Mittelwert aus den Stichprobendaten zu schätzen. Dieser Gedanke
führt auf den t-Test.
93
Grundlagen
Der t-Test ermöglicht es, Aussagen über den Mittelwert eines Merkmals
zu treffen, ohne die Varianz der zugrundeliegenden Verteilung zu kennen.
Die Anwendung des t-Tests setzt voraus, daß das interessierende Merkmal
einer Normalverteilung folgt. Ist dies nicht der Fall, so kann man den tTest trotzdem anwenden, wenn der Stichprobenumfang groß genug ist (ab
etwa n ≥ 30), da dann aufgrund des Zentralen Grenzwertsatzes das Stichprobenmittel X angenähert normalverteilt ist. Das Ergebnis gilt dann nur
approximativ, für n ≥ 30 ist der Approximationsfehler aber vernachlässigbar
klein.
Die Grundlage des t-Tests ist die sogenannte Student-t-Verteilung, auf
deren Herleitung hier nicht eingegangen wird. Die t-Verteilung hat einen
Parameter n, die Freiheitsgrade der Verteilung. Ist eine Zufallsvariable X
t-verteilt mit n Freiheitsgraden, so schreibt man dies als X ∼ tn . Die
Teststatistik T des t-Tests ist eine t-verteilte Zufallsvariable, die aus den
Punktschätzern (3) und (4) für Stichprobenmittelwert und Stichprobenvarianz ähnlich wie in den Abschnitten 1.3 und 3.7 wird:
T = T (X1 , . . . , Xn ) =
4.1
X − µ0 √ X − µ0
= n· √
.
σ̂X
S2
(12)
Der t-Test für eine Stichprobe
Wir betrachten zunächst den einfachen Fall, in dem eine Stichprobe eines
einzelnen Merkmals X gezogen wird. Voraussetzung ist, wie oben dargelegt,
daß X entweder normalverteilt ist oder aber der Stichprobenumfang n ≥ 30
ist. Die zu testende Alternativhypothese trifft eine Aussage über den Mittelwert µ des Merkmals und ist entweder eine zweiseitige, eine rechtsseitige
oder eine linksseitige Hypothese.
Beispiel 1. Eine Fachzeitschrift testet die Qualität des automatischen
Weißabgleichs einer Digitalkamera. Hierzu schießt die Redaktion n = 100
Bilder des gleichen Motivs mit bekanntem Weißpunkt und ermittelt für jeden Schnappschuß den von der Kamera gewählten Weißpunkt. Die Frage ist,
ob der durchschnittlich von der Kamera gewählte Weißpunkt µ gleich dem
wahren Weißpunkt µ0 ist, es handelt sich also um einen zweiseitigen Test mit
H0 : µ = µ0 . Der t-Test kann wegen der hohen Stichprobengröße unabhängig
von der tatsächlichen Verteilung angewendet werden.
Beispiel 2. Ein Jäger vermutet, daß sein Jagdgewehr eine Abweichung nach
rechts zeigt. Er gibt fünf Schüsse auf eine Zielscheibe ab und mißt die Entfernung vom Mittelpunkt in der Horizontalen. Mit diesen Daten führt er einen
94
4 t-Test
rechtsseitigen Test H1 : µ > 0 durch. Da die Abweichung einer Vielzahl von
Einflüssen unterliegt, wird sie als normalverteilt angenommen. Der t-Test
kann also auch bei dieser geringen Stichprobengröße zum Zuge kommen.
√
√ 0 (siehe GleDie entsprechende Teststatistik des t-Tests ist T = n · X−µ
S2
ichung (12)), die kritischen Bereiche sind K = (t∗n−1;1−α , ∞) für einen
rechtsseitigen Test, K = (−∞, t∗n−1;α ) für einen linksseitigen Test und
K = (−∞, −t∗n−1;1− α ) ∪ (t∗n−1;1− α , ∞) für einen zweiseitigen Test (Herleitung
2
2
analog zu Abschnitt 3.7).
4.2
t-Test für unabhängige Stichproben
In vielen Fällen aus der Praxis kommt in einer Studie nicht nur ein Merkmal
vor, sondern es werden mehrere Merkmale erhoben und miteinander verglichen. So interessiert z. B. der Unterschied zwischen dem Behandlungserfolg zweier Therapietechniken oder die Wirksamkeit zweier Lehrmethoden,
jeweils modelliert als zwei Zufallsvariablen X und Y . Dies ist der Zweistichprobenfall. Man nennt X und Y auch Treatments.
Zwei Stichproben heißen voneinander unabhängig, falls ihre jeweiligen
Stichprobenvariablen voneinander unabhängig sind. Dies kann z. B. dadurch
realisiert werden, daß zur Erhebung der Merkmale X und Y jeweils unterschiedliche Personen4 untersucht werden. Beispiel : Medikamententest –
Patienten aus Gruppe 1 werden mit Medikament A, Patienten aus Gruppe 2
mit Medikament B behandelt. Werden die Merkmale an ein und demselben
Objekt erhoben (z. B. Blutwerte vor und nach einer Medikamentengabe), so
handelt es sich um abhängige Stichproben, die mit dem Verfahren aus dem
nächsten Abschnitt behandelt werden müssen.
Man beachte, daß für X und Y nicht unbedingt dieselbe Anzahl von Messungen vorliegen muß. So können z. B. n Stichprobenvariablen X1 , . . . , Xn
für X existieren und gleichzeitig m 6= n Stichprobenvariablen Y1 , . . . , Ym für
Y . Die Voraussetzungen für die Anwendbarkeit des t-Tests (neben der Unabhängigkeit der Stichprobenvariablen voneinander) sind, daß X normalverteilt
ist oder n ≥ 30 gilt und daß Y normalverteilt ist oder m ≥ 30 gilt.
Die Hypothesen treffen im Fall unabhängiger Stichproben keine Aussagen
mehr über den Erwartungswert einer Zufallsvariablen, sondern über den Unterschied der Erwartungswerte der beiden Zufallsvariablen X und Y :
H 0 : µX = µY
H 0 : µX ≤ µY
H 0 : µX ≥ µY
4
H1 : µX 6= µY
H 1 : µX > µ Y
H 1 : µX < µ Y
zweiseitiger Test
rechtsseitiger Test
linksseitiger Test
allgemein: Objekte aus der Grundgesamtheit
95
Grundlagen
2
Bezeichnen X, SX
, Y , SY2 die Schätzer für Stichprobenmittel und -varianz
von X1 , . . . , Xn bzw. Y1 , . . . , Ym , so benutzt der t-Test für unabhängige Stichproben folgende Prüfgröße T :
X −Y
T =q 2
.
SX
SY2
+ m
n
(13)
Der Wert dieser Prüfgröße wird gegen den kritischen Wert einer tVerteilung mit f Freiheitsgraden getestet, wobei der genaue Wert von f von
den Stich”-pro”-ben”-um”-fän”-gen und den geschätzten Varianzen abhängt.
Im Spezialfall, daß die Varianzen von X und Y zwar unbekannt sind, aber
bekannt ist, daß Var X = Var Y gilt, ist f = n + m − 2. Der kritische Bereich
K ist gegeben durch:
(−∞, −t∗f ;1− α ) ∪ (t∗f ;1− α , ∞)
zweiseitiger Test
(t∗f ;1−α , ∞)
rechtsseitiger Test
(−∞, t∗f ;α )
linksseitiger Test
2
2
Abschließend sei noch angemerkt, daß man den t-Test verallgemeinern
kann, so daß nicht nur ein Unterschied zwischen den beiden Mittelwerten
erkannt wird, sondern auch die Größe dieses Unterschiedes getestet wird.
4.3
t-Test für abhängige Stichproben
Können wir die Unabhängigkeit zweier Stichproben nicht voraussetzen, so
müssen wir unser Modell etwas modifizieren. Wir modellieren die Stichproben als eine Menge von Paaren von Zufallsvariablen (X1 , Y1 ), . . . , (Xn , Yn ),
wobei Xi und Yi nicht voneinander unabhängig sein müssen. Dies ist
dann nicht der Fall, wenn die beiden Werte am selben Untersuchungsobjekt gemessen wurden, z. B. Hebeleistung eines Gewichthebers vor und nach
Beginn einer Diät. Der t-Test für unabhängige Stichproben kann nicht zur
Anwendung kommen, da wir die beiden Mittelwerte X und Y nicht mehr als
unabhängig betrachten und entsprechend nicht mehr die Varianzen gemäß der
Methoden aus dem vorigen Abschnitt schätzen können. Stattdessen bilden
wir die Differenz der beiden Zufallsvariablen D = X − Y und erhalten so für
jedes Paar (Xi , Yi ) eine neue Stichprobenvariable Di = Xi − Yi .
Das restliche Vorgehen ist analog zum Einstichprobenfall, nur daß die
Stichprobe aus D1 , . . . , Dn zusammengesetzt ist. Die möglichen Hypothesen
96
5 Anwendungsbeispiel und Probleme
lauten also:
H 0 : µD = 0 H 1 : µ D =
6 0 zweiseitiger Test
H0 : µD ≤ 0 H1 : µD > 0 rechtsseitiger Test
H0 : µD ≥ 0 H1 : µD < 0 linksseitiger Test
Die Prüfgröße ist
T =
√
n·
D
,
SD
p
2
wobei SD =
SD
die geschätzte Standardabweichung der Differenzenverteilung D ist. T folgt einer t-Verteilung mit n − 1 Freiheitsgraden, die
kritischen Werte sind also dieselben wie in Abschnitt 4.1.
5
Anwendungsbeispiel und Probleme
Zum Abschluß sollen alle besprochenen Punkte noch einmal an einem fiktiven
Beispiel zur Anwendung kommen, um ihr Zusammenspiel untereinander herauszuarbeiten.
5.1
Fragestellung und Hypothesenformulierung
Wir betrachten den Fall, daß ein Veranstalter einer jährlich stattfindenden
wissenschaftlichen Konferenz untersuchen möchte, ob es für die Qualität der
eingereichten Beiträge besser ist, das Ende der entsprechenden Frist von
einem Freitag auf einen Sonntag zu verlegen. Um dies herauszufinden, vergibt
er für diverse termingebundene Abgaben von wissenschaftlichen Assistenten
nach dem Zufallsprinzip entweder einen Freitag oder einen Sonntag als Abgabetermin und bewertet die abgegebenen Arbeiten.
Als Ergebnis erhält er zwei Stichproben für die Variablen QFr und QSo ,
die die Qualität der eingereichten Arbeiten mit Stichtag Freitag bzw. Sonntag darstellen. Da untersucht werden soll, ob die Verlegung des Termins
auf Sonntag einen Vorteil bringt, lautet die erste Hypothese HSo : µSo > µFr ,
wobei µFr und µSo die Mittelwerte darstellen. Die entsprechend entgegengesetzte Hypothese besagt, daß die Verlegung keinen Vorteil bringt, und wird
als HFr : µSo ≤ µFr formuliert.
Nach dem ersten Prinzip eines jeden Verwaltungsapparats (”‘Das haben
wir schon immer so gemacht.”’) wird es für eine eventuelle Terminverlegung
einen Rechtfertigungsdruck geben. Wird jedoch nichts verändert, so sind
bis auf die Möglichkeit einer statistischen Fehlentscheidung keine negativen
97
Grundlagen
Konsequenzen zu erwarten. Von daher sind Null- und Alternativhypothese
wie folgt zu wählen:
H0 = HFr : µSo ≤ µFr
H1 = HSo : µSo > µFr
Damit sich der Aufwand der Terminverschiebung auch lohnt, legt der Veranstalter einen mindestens geforderten Qualitätsunterschied von q0 Punkten auf seiner Qualitätsskala fest. Es handelt sich also bei dem gegebenen
Testproblem um einen Test mit rechtsseitiger (gerichteter), spezifischer Unterschiedshypothese.
5.2
Testauswahl und Anforderungsbestimmung
Der Veranstalter nimmt an, daß die Qualität außer von der Abgabefrist noch
von vielen anderen Faktoren abhängt und dementsprechend normalverteilt
ist. Da ihm die Streuung (die Varianz) jedoch nicht bekannt ist, wird er
diese aus den erhobenen Daten schätzen. Trotzdem kann er davon ausgehen,
daß die Varianz bei Abgabe an einem Freitag gleich der Varianz bei Abgabe an einem Sonntag ist. Da die Arbeiten unabhängig voneinander entstehen und insbesondere von unterschiedlichen Merkmalsträgern stammen, handelt es sich um unabhängige Stichproben. Beide Punkte zusammengenommen führen auf den t-Test für unabhängige Stichproben aus Abschnitt 4.2
als geeignetes Testverfahren. Da für das Merkmal eine Normalverteilung
angenommen wurde, kann der Test auch mit kleinen Stichproben durchgeführt werden, was es dem Veranstalter erspart, 60 Beiträge zu bewerten.
Als nächstes ist die Irrtumswahrscheinlichkeit festzulegen. Da die Konsequenzen einer Terminverschiebung zwar nicht gravierend sind, dem Veranstalter aber eventuell einige Umstände bereiten könnten, entschließt er
sich, den Termin nur zu verschieben, falls er einen signifikanten Unterschied
feststellt. Somit legt er α = 0,05 fest.
Da er einen Unterschied von mindestens q0 Punkten fordert, kann er
sowohl die Effektgröße als auch die β-Fehlerwahrscheinlichkeit bestimmen
und berechnet aus diesen Größen einen Stichprobenumfang n, der bei jedem
möglichen Ergebnis eine eindeutige Entscheidung erlaubt. Auf diese Weise
läuft er nicht Gefahr, ein indifferentes Ergebnis zu erhalten und die Stichprobe wiederholen zu müssen.
5.3
Durchführung
Nun sind alle freien Parameter bestimmt, und die Erhebung der Stichprobe
kann beginnen. Als Ergebnis erhält der Veranstalter eine konkrete Stichprobe
98
References
So
q1Fr , . . . , qnFr , q1So , . . . , qm
mit n vielen bewerteten Arbeiten, die an einem Freitag abgegeben werden mußten, und m vielen, deren Abgabetermin an einem
Sonntag lag.
Gemäß (13) berechnet er aus diesen Daten zunächst das Stichprobenmittel und die Stichprobenvarianz sowohl für QFr als auch für QSo und aus
diesen die Prüfgröße T . Da die Varianzen als gleich vorausgesetzt wurden,
ist T t-verteilt mit n + m − 2 Freiheitsgraden. Den kritischen Bereich für
die Prüfgröße bestimmt der Veranstalter für diesen rechtsseitigen Test zum
Niveau α als (t∗n+m−2;1−α , ∞).
Schließlich überprüft er, ob der berechnete Wert für die Teststatistik innerhalb oder außerhalb des kritischen Bereichs liegt. Liegt der Wert innerhalb
des kritischen Bereichs, so schlußfolgert der Veranstalter, daß die Verlegung
der Abgabefrist auf einen Sonntag die Qualität der eingereichten Arbeiten
signifikant verbessern würde. Auf diese Weise erreicht er durch die Verlegung
eine bessere Konferenz auf Kosten des Wochenendes vieler Autoren.
References
[Bor05] Jürgen Bortz. Statistik für Human- und Sozialwissenschaftler.
Springer, 6. auflage edition, 2005.
[GB05] Ulrike Genschel and Claudia Becker. Schließende Statistik. Springer,
2005.
[Sch01] Volker Schmidt. Stochastik für informatiker, physiker, chemiker
und wirtschaftswissenschaftler. http://www.mathematik.uni-ulm.
de/stochastik/lehre/ss01/stochInfWi/vs1.ps, Juli 2001. Vorlesungsskript an der Universität Ulm.
99
Mehrfaktorielle Versuchspläne und
Messwiederholungen
Sebastian Wehlmann
Grundlagen
1
Grundlagen
Im ersten Kapitel soll zunächst der Sinn und Zweck einer Varianzanalyse erläutert werden. Danach werden einige, für die Behandlung von Varianzanalysen wichtige, Begriffe vorgestellt. Anhand eines Beispiels von verschiedenen
medizinischen Behandlungsformen wird anschließend ausführlich das Prinzip
der einfaktoriellen Varianzanalyse vorgestellt, welches als Grundlage für die
zwei- und mehrfaktorielle Varianzanalyse gilt.
1.1
Motivation
Die Varianzanalyse (kurz: ANOVA = ”ANalysis Of VAriance”) wird dazu
benutzt, Differenzen zwischen Mittelwerten abzusichern ähnlich wie dies der
t-Test liefert. Der t-Test vergleicht dabei immer die Mittelwerte zweier
Versuchsobjekte miteinander und überprüft die Wahrscheinlichkeit der gefundenen Mittelwertsdifferenz unter Annahme der Nullhypothese. Ist diese
Wahrscheinlichkeit sehr gering, so besteht mit einer bestimmten Fehlerwahrscheinlichkeit α ein systematischer Unterschied zwischen den Versuchsobjekten.1
Der große Vorteil der Varianzanalyse gegenüber dem t-Test liegt nun in
der Untersuchung großer Mengen an Mittelwerten. Während beim t-Test
wie beschrieben für jedes Mittelwertpaar ein eigener Test durchgeführt werden muss, kann die Varianzanalyse direkt alle Mittelwerte in die Berechnung aufnehmen. Würde man statt einer Varianzanalyse mehrere t-Tests
machen, so könnte sich das α-Niveau vergrößern, da die α-Fehler aller tTests aufsummiert werden müssen. So kann es sein, dass zwar jeder einzelne
t-Test gegen das a priori festgelegte Niveau testet, dieses Niveaus sich jedoch zu einem größeren Gesamt-α-Niveau addieren. Man spricht hier auch
von α-Fehlerkumulierung (kumulieren = anhäufen). Ein weiteres ”Problem”
bei der Durchführung mehrerer t-Tests ist die Tatsache, dass hierbei immer
nur Teile der gesamten Messwerte in die Analyse mit eingehen. Bei drei
zu vergleichenden Gruppen berücksichtigt ein einzelner t-Test zum Beispiel
lediglich 2/3 aller Versuchsobjekte (gleiche Stichprobengröße vorausgesetzt).
Die Teststärke der Varianzanalyse ist also für die Behandlung von mehr als
zwei Mittelwerten größer als die der entsprechenden t-Tests.
1
Für eine genaue Beschreibung des t-Tests sei an dieser Stelle auf die entsprechende
Ausarbeitung verwiesen.
102
1 Grundlagen
1.2
Begriffe
Zum Verständnis der Varianzanalyse sind einige Begriffe grundlegend. Der
wohl wichtigste Begriff ist dabei die Varianz. Die Varianz gibt die mittlere
Abweichung jedes einzelnen Wertes vom Mittelwert einer Verteilung an.
Formell bedeutet dies:
n
P
(xi − x)2
i=1
2
σ
bx =
n−1
Dabei beschreibt n die Anzahl aller Werte, xi den i-ten Wert der Variablen
x und x den Mittelwert aller Werte von x.
Die Summe über alle quadrierten Abweichungen vom Mittelwert (der Term
im Zähler), wird oftmals als Quadratsumme (QS) bezeichnet.
n
P
Es gilt: QSx = (xi − x)2
i=1
Der Nenner der Varianz beschreibt die Anzahl der Freiheitsgrade df .
Hier gilt: dfx = n − 1
Man kann die Varianz also auch als Differenz von Quadratsumme und Freiheitsgrad schreiben:
QSx
σ
bx2 =
dfx
Letztere Schreibweise wird im folgenden bevorzugt verwendet.
Das Merkmal, dessen Varianz durch eine Varianzanalyse untersucht wird, bezeichnet man als abhängige Variable. Im Gegensatz dazu beschreibt eine
unabhängige Variable diejenige Variable, welche Einfluss auf das Ergebnis der Varianzanalyse haben kann. U.a. wird die Varianzanalyse durch die
Anzahl der unabhängigen Variablen klassifiziert. So wird etwa eine Varianzanalye, die den Einfluss einer unabhängigen Variablen auf die abhängige
Variable überprüft als ”einfaktorielle Varianzanalyse” bezeichnet.
Die gewählte Unterteilung der unabhängigen Variablen bezeichnet man als
Faktor. Wird beispielsweise eine unabhängige Variable ”Parteien” in 5
Parteien unterteilt, so spricht man von einem 5 fach gestuften Faktor.
Ein weiterer wichtiger Begriff ist der des Treatments. Werden randomisierte
Stichproben unterschiedlich behandelt, so wird die unabhängige Variable als
Treatmentfaktor oder kurz Treatment bezeichnet.
1.3
Prinzip der einfaktoriellen Varianzanalyse
Das Grundprinzip der einfaktoriellen Varianzanalyse (auch ”unifaktorielle
Varianzanalyse” genannt) soll in diesem Kapitel näher erläutert werden.
103
Grundlagen
Dabei wird zunächst in allgemeiner Form die Terminologie eingeführt, welche
dann durch ein konkretes Beispiel veranschaulicht werden soll. Anhand dieses
Beispiels werden Grundlagen zu Nullhypothesen, Quadratsummenzerlegungen und Signifikanztests erörtert, welche für das weitere Verständnis der Varianzanalyse unabdingbar sind und in späteren Kapiteln immer wieder auftauchen und gebraucht werden.
1.3.1
Terminologie
Zur Darstellung dieser Daten verwendet man eine Datenmatrix, welche allgemein aus p Spalten für eine p fach gestufte unabhängige Variable und n Zeilen
für n viele Versuchsergebnisse besteht. x22 repräsentiert somit beispielsweise
den zweiten Wert der zweiten Faktorstufe.
Die Summe aller Werte einer Faktorstufe i wird mit Ai bezeichnet. Der
Mittelwert Ai aller Werte einer Faktorstufe i ergibt sich, wenn man die
Summe aller Werte der entsprechenden Faktorstufe durch die Anzahl n selbiger Werte teilt. Desweitern kann die Gesamtsumme G aller Messwerte aller
Faktorstufen bestimmt werden sowie deren Mittelwert G.
Allgemeine Darstellung:
Faktor A
1
2
x11 x12
x21 x22
..
..
.
.
···
···
···
xm1
..
.
xm2
..
.
xn1
xn2
Ai =
n
P
···
···
···
···
i
x1i
x2i
..
.
xmi
..
.
xni
···
···
···
···
···
···
···
p
x1p
x2p
..
.
xmp
..
.
xnp
xmi
m=1
Ai = Ai /n
p
p
n P
P
P
xmi =
Ai
G=
m=1 i=1
i=1
G = G/(n · p)
Zur weiteren Illustration diene nun folgendes Beispiel:
Es sollen drei Behandlungsmethoden, die sich durch unterschiedliche
Medikamente A, B und C unterscheiden, bzgl. ihres Heilungserfolges (hier
messbar als ganze Zahl zwischen 1 und 15) verglichen werden. Dazu werden
104
1 Grundlagen
jeweils 4 Personen mit den unterschiedlichen Medikamenten behandelt.
Insgesamt nehmen also 3 · 4 = 12 Personen an der Untersuchung teil. In
diesem Beispiel sind die Behandlungsmethoden die unabhängige Variable
und der Heilungserfolg die abhängige Variable.
Behandlungsmethoden
A
7
8
6
7
Summen (Ai ):
28
Mittelwerte (Ai ): 7
1.3.2
B
10
11
11
12
44
11
C
11
12
12
13
48
12
Nullhypothese
Die Häufigste Hypothese, die mit der einfaktoriellen Varianzanalyse überprüft wird, ist die sogenannte Nullhypothese. Sie besagt, dass sich alle
Mittelwertparameter µi der entsprechenden Faktorstufen nicht unterscheiden.
Es gilt: H0 : µ1 = µ2 = · · · = µp
1.3.3
Quadratsummenzerlegung
Die einfaktorielle Varianzanalyse geht nun von folgendem Ansatz aus: Eine
durch die Gesamtvarianz aller Messwerte ermittelte Unterschiedlichkeit in
den einzelnen Versuchsergebnissen wird auf deren Abhängigkeit zu den verschiedenen Stufen der unabhängigen Variablen geprüft. Bei genügend großer
Abhängigkeit wird die H0 verworfen und behauptet, die unterschiedlichen
Stufen der unabhängigen Variablen führen zu signifikant unterschiedlichen
Ergebnissen.
1.3.4
Totale Quadratsumme
Als totale Quadratsumme (QStot ) bezeichnet man die Quadratsumme, welche
zur Bestimmung der Varianz aller Messwerte benötigt wird. Diese Gesamtvarianz ergibt sich durch Division der Summe der quadrierten Abweichungen
aller Messwerte vom Mittelwert und der Anzahl der Freiheitsgrade der VariMethoden der empirischen Softwaretechnik
105
Grundlagen
anz (vgl. Kapitel 1.2):
m
P
σ
bx2 =
(xi − G)2
i=1
n−1
Für das Beispiel muss also zunächst der Mittelwert aller Messwerte gebildet
werden:
G = 28+44+48
= 120
= 10
12
12
Desweiteren benötigen wir die quadrierten Abweichungen aller Messwerte
von G:
A
9
4
16
9
m
P
B
0
1
1
4
C
1
4
4
9
(xi − G)2 : 38 6
18
i=1
Wird nun noch die Summe über alle Spaltensummen gebildet, so erhalten
wir die totale Quadratsumme QStot :
QStot =
p
n
X
X
(xmi − G)2
i=1 m=1
Auf das Beispiel bezogen bedeutet das: QStot = 38 + 6 + 18 = 62
2
Die Gesamtvarianz σ
btot
ist dann nach obiger Formel die Differenz der totalen
Quadratsumme und der Anzahl der Freiheitsgrade. Da für die Anzahl der
Freiheitsgrade gemäß allgemeiner Definition dftot = n · p − 1 gilt, ergibt sich
insgesamt:
p P
n
P
(xmi − G)2
2
σ
btot
= QStot /dftot = i=1 m=1
n·p−1
2
Konkret: σ
btot
=
1.3.5
62
11
≈ 5,63
Treatmentquadratsumme
Als nächstes wird nun der Teil der Unterschiedlichkeit zwischen den
gemessenen Werten bestimmt, der auf die unterschiedlichen Stufen der
unabhängigen Variablen zurück zu führen ist. Man nehme an, dass lediglich
diese unterschiedlichen Stufen für die Varianz verantwortlich wären, dann
dürften sich die Messwerte einer Faktorstufe innerhalb dieser Stufe nicht
106
1 Grundlagen
unterscheiden. Als beste Schätzung ergibt sich hier der Durchschnittswert
jeder Stufe, da dieser unter der obigen Annahme gleich dem tatsächlichen
Wert sein muss.
Für das Beispiel ergibt sich damit folgende Datenmatrix:
A
7
7
7
7
B
11
11
11
11
C
12
12
12
12
Um die Unterschiedlichkeit nun zu bestimmen, werden (wie bei der
Bestimmung der totalen Quadratsumme QStot ) wieder die quadrierten Abweichungen der Messwerte vom Gesamtmittelwert G aufsummiert. Konkret
bedeutet das, dass die quadrierten Abweichungen von G = 10 zu bestimmen
sind:
A
9
9
9
9
2
n · (Ai − G) : 36
B
1
1
1
1
4
C
4
4
4
4
16
Die Spaltensummen repräsentieren wiederum die Summe der quadrierten Abweichungen, die nur vom entsprechenden Medikament abhängen.
Die Treatmentquadratsumme QStreat berechnet sich nun aus der Summe
aller Spaltensummen.
p
P
Es gilt: QStreat =
n · (Ai − G)2 = 36 + 4 + 16 = 56
i=1
Für die Anzahl der Freiheitsgrade der QStreat gilt folgende Überlegung: Von
den p Treatmentstufenmittelwerten können bei festgelegtem G genau p − 1
Werte variieren.
Es gilt: dftreat = p − 1
Für die Varianz gilt demnach:
n·
2
σ
btreat
= QStreat /dftreat =
2
Und im Speziellen: σ
btreat
=
56
2
p
P
(Ai − G)2
i=1
p−1
= 28
107
Grundlagen
1.3.6
Fehlerquadratsumme
Der Teil der Varianz, der nicht auf den Treatmentstufen beruht, wird als
Fehlervarianzanteil bezeichnet und ist auf Messungenauigkeiten, unterschiedliche Begabung oder Motivation etc. zurück zu führen. Aufgabe
ist nun, die Größe dieses Fehlervarianzanteiles zu bestimmen. Dazu wird
zunächst der Anteil, der idealerweise ausschließlich auf der entsprechenden
Faktorstufe beruht, eliminiert. Die Überlegungen zur Treatmentquadratsumme haben gezeigt, dass dieser am Besten durch die Mittelwerte der
entsprechenden Stufen abgeschätzt werden kann. Man zieht also von jedem
Messwert den Faktorstufenmittelwert Ai ab, wobei die Spaltensummen
dabei logischerweise gleich 0 sein müssen.
Für das Beispiel ergibt sich folgendes:
A
0
1
-1
0
n
P
(xmi − Ai ): 0
B
-1
0
0
1
C
-1
0
0
1
0
0
m=1
Um die Fehlerquadratsumme zu bestimmen, werden nun die Abweichungen
der Werte vom jeweiligen Mittelwert der Faktorstufe quadriert und pro
Gruppe summiert.
Es gilt:
n
P
A
0
1
1
0
B
1
0
0
1
C
1
0
0
1
(xmi − Ai )2 : 2
2
2
m=1
Die Spaltensummen ergeben
QSF ehler(i) .
Für das Beispiel lauten sie:
QSF ehler(1) = 2
QSF ehler(2) = 2
108
pro
Gruppe
die
Fehlerquadratsumme
1 Grundlagen
QSF ehler(3) = 2
Für die Summe der Fehlerquadratsummen gilt:
p
P
QSF ehler =
QSF ehler(i) = 2 + 2 + 2 = 6
i=1
Zur Bestimmung der Varianz werden wieder die Freiheitsgrade benötigt. Da
die Summe der Abweichungen innerhalb einer Gruppe gleich Null sein muss,
können n − 1 Summanden frei variieren.
Bei n = 4 in dem Beispiel ergibt sich:
σ
bF2 ehler(i) =
σ
bF2 ehler(1) =
σ
bF2 ehler(2) =
σ
bF2 ehler(3) =
QSF ehler(i)
(n−1)
2
≈ 0,67
3
2
≈ 0,67
3
2
≈ 0,67
3
Die durchschnittliche Varianz, welche zur Fehlervarianzschätzung benötigt
wird, erhält man nun, indem man die Summe der Fehlerquadratsummen
durch die Summe der Freiheitsgrade teilt:
p
P
σ
bF2 ehler
=
QSF ehler(i)
i=1
p
P
dfF ehler(i)
i=1
Im Speziellen: σ
bF2 ehler =
2+2+2
3+3+3
=
6
9
≈ 0,67
Es gelten zusammenfassend folgende Zusammenhänge:
QStreat + QSF ehler = QStot
dftreat + dfF ehler = dftot
1.3.7
Varianzaufklärung
Die Varianzaufklärung beschreibt die prozentuale Gesamtunterschiedlichkeit der Treatmentquadratsumme zur totalen Quadratsumme.
treat
Allgemein gilt: Varianzaufklärung = QS
· 100%
QStot
Für das Beispiel ergibt sich
1.3.8
56
62
· 100% ≈ 90,32%
Signifikanztest
Abschließend muss nun überprüft werden ob die Varianzaufklärung zufällig
aufgrund der Stichprobenauswahl zustande gekommen ist, oder ob es signifikante Unterschiede in den Stufen der unabhängigen Variablen gibt. Dazu
109
Grundlagen
wird angenommen, dass die Nullhypothese gilt, also alle Stufen gleich zu bewerten sind, und die Wahrscheinlichkeit bestimmt, dass die errechneten Unterschiede in den Mittelwerten zufällig sind. Ist die Wahrscheinlichkeit dabei
kleiner als ein vorher zu bestimmender Grenzwert α (üblicherweise α = 1%
oder α = 5%), so wird die H0 verworfen. Man sagt, dass sich in diesem
Fall die gefundenen Werte in mindestens zwei Fällen signifikant voneinander
unterscheiden. Andernfalls wird die H0 beibehalten und man bewertet die
Mittelwertsunterschiede als zufällig.
Die H0 , dass zwei voneinander unabhängige Variablen identisch sind, wird
über den F-Test geprüft.
Es gilt:
σ
b2
F = 2treat
σ
bF ehler
28
Für das Beispiel gilt: F = 0,67
≈ 41,79
Durch Nachschlagen in speziellen Tabellen kann dieser Wert mit dem für p−1
Zählerfreiheitsgrade und p·(n−1) Nennerfreiheitsgrade zu erwartenden Wert
auf dem gewählten Grenzwertniveau verglichen werden.
Für das Beispiel ergibt sich auf dem 1%-Niveau bei p = 3 und n = 4 ein
kritischer Wert von 8,02. Da der empirische Wert größer als der kritische
Wert ist, wird die Nullhypothese verworfen.
Die drei verschiedenen Behandlungsformen unterscheiden sich also signifikant
voneinander.
2
Mehrfaktorielle Versuchspläne
Dieses Kapitel beschreibt die Anwendung und das Verfahren der mehrfaktoriellen Varianzanalyse. Dabei werden zunächst die Gründe für mehrfaktorielle Versuchspläne und deren Vorteile gegenüber den einfaktoriellen
Plänen diskutiert. Anschließend wird das bereits bekannte Beispiel der
Wirkungsweise unterschiedlicher Medikamente auf unterschiedliche Versuchspersonen zwei bzw. ansatzweise mehrfaktoriell ausgebaut und daran
die veränderte Behandlung und Berechnung von Quadratsummen, Nullhypothesen und Signifikanztests erläutert.
2.1
Motivation
Die Varianzanalyse ist nicht nur eine Verallgemeinerung des t-Tests auf
mehrere Faktorstufen, es können auch Varianzanalysen mit mehreren Faktoren durchgeführt werden, wobei die Faktoren mindestens zwei Faktorstufen
aufweisen. Dies ermöglicht eine stärkere Differenzierung der Messwerte.
110
2 Mehrfaktorielle Versuchspläne
Dabei gehen mehrfaktorielle Varianzanalyse in der Regel effizienter mit den
Daten um, das heißt, dass man mit Hilfe einer mehrfaktoriellen Varianzanalyse weniger Beobachtungen braucht, um Effekte nachzuweisen. Von besonderem Interesse ist auch ein mögliches Zusammenwirken (Wechselwirkung)
der untersuchten Faktoren.
2.2
Zweifaktorielle Versuchspläne
Dieses Kapitel beschreibt die Vorgehensweise bei der zweifaktoriellen Varianzanalyse. Analog zur einfaktoriellen Varianzanalyse wird zunächst eine
Quadratsummenzerlegung und Freiheitsgrad-Berechnung durchgeführt, um
anschließend Varianzschätzungen vornehmen zu können. Danach werden
Nullhypothesen definiert, die durch den F -Test überprüft werden können.
Zum Abschluss wird kurz die Verwendung von Interaktionsdiagrammen angerissen.
2.2.1
Terminologie
Wie bereits von der einfaktoriellen Analyse bekannt wird zur Darstellung der
Daten eine Datenmatrix verwendet. Diese besteht nach wie vor aus p Spalten für eine p fach gestufte unabhängige Variable (Faktor A) und zusätzlich
q Zeilen für eine q fach gestufte zweite unabhängige Variable (Faktor B).
Welche der beiden Variablen welchem Faktor zugeordnet wird spielt dabei
keine Rolle.
111
Grundlagen
Allgemeine Darstellung:
1
x111
x112
.
1 ..
x11m
..
.
Faktor A
2
···
x211 · · ·
x212 · · ·
..
.
···
x21m
..
.
x11n
x121
x122
.
2 ..
x12m
..
.
x21n
x221
x222
..
.
x12n
..
.
x22n
..
.
x1j1
x1j2
.
j ..
x1jm
..
.
x2j1
x2j2
..
.
x1jn
..
.
x2jn
..
.
x1q1
x1q2
.
q ..
x1qm
..
.
x2q1
x2q2
..
.
x1qn
x2qn
Faktor B
x22m
..
.
x2jm
..
.
x2qm
..
.
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
i
xi11
xi12
..
.
xi1m
..
.
xi1n
xi21
xi22
..
.
xi2m
..
.
xi2n
..
.
xij1
xij2
..
.
xijm
..
.
xijn
..
.
xiq1
xiq2
..
.
xiqm
..
.
xiqn
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
···
p
xp11
xp12
..
.
xp1m
..
.
xp1n
xp21
xp22
..
.
xp2m
..
.
xp2n
..
.
xpj1
xpj2
..
.
xpjm
..
.
xpjn
..
.
xpq1
xpq2
..
.
xpqm
..
.
xpqn
Zum besseren Verständnis bemühe man noch einmal das Beispiel der
unterschiedlichen Behandlungsmethoden mit unterschiedlichen Medikamenten wie es bei der Beschreibung der einfaktoriellen Varianzanalyse
bereits verwendet worden ist. Man könnte die jeweils vier Personen je
Medikament noch ein zweites mal unterteilen. Als Unterscheidungsmerkmal
würde sich zum Beispiel das Geschlecht anbieten. Es wird also neben der
112
unabhängigen Variablen ”Medikament” (A,B,C) eine zweite unabhängige
Variable ”Geschlecht” (männlich, weiblich) eingeführt.
Das Beispiel sieht dann wie folgt aus:
Behandlungsmethoden
A
männlich
7
8
weiblich
6
7
Summen (Ai ):
28
Mittelwerte (Ai ): 7
B
10
11
11
12
44
11
C
11
12
12
13
48
12
Es soll nun überprüft werden, ob die Unterteilung Einfluss auf die
Fehlervarianz hat.
2.2.2
Das Vorgehen ist hier ähnlich wie bei der einfaktoriellen Varianzanalyse. Die
Berechnung der totalen Quadratsumme ist hierbei sogar identisch. Da die
Werte des Beispiels nicht verändert wurden, kann man die QStot übernehmen.
Es gilt: QStot = 62
Als nächstes wird wie bei der Treatmentquadratsumme wieder von idealisierten Werten je Faktorstufe ausgegangen. Wie bereits gezeigt wurde erweisen sich hier die Mittelwerte als gute Näherung. Der Unterschied zur einfaktoriellen Analyse besteht darin, dass nun die Mittelwerte je Stufe des Faktors B unterschieden werden. Für das Beispiel bedeutet dies, dass zwischen
den Mittelwerten der weiblichen und männlichen Personen je Medikament
unterschieden wird. Die Quadratsumme, die durch die Summe der quadrierten Abweichungen der Mittelwerte vom Gesamtmittelwert G entsteht, wird
als Quadratsumme der Zellen (QSZellen ) bezeichnet.
Konkret bedeutet das:
QSZellen = 2 · (7,5 − 10)2 + 2 · (6,5 − 10)2 + 2 · (10,5 − 10)2 + 2 · (11,5 − 10)2 +
2 · (11,5 − 10)2 + 2 · (12,5 − 10)2 = 59
Die Fehlerquadratsumme berechnet sich aus der Summe aller quadratischen Abweichungen der Messwerte von den jeweiligen Zellenmittelwerten:
QSF ehler = (7 − 7,5)2 + (8 − 7,5)2 + (6 − 6,5)2 + (7 − 6,5)2 + (10 − 10,5)2 +
(11 − 10,5)2 + (11 − 11,5)2 + (12 − 11,5)2 + (11 − 11,5)2 + (12 − 11,5)2 + (12 −
12,5)2 + (13 − 12,5)2 = 3
Diese Schritte haben sich bis jetzt nicht von der Vorgehensweise bei der einMethoden der empirischen Softwaretechnik
113
Grundlagen
faktoriellen Varianzanalyse unterschieden. Es wurde lediglich eine ”feinere”
Untersuchung in Zellen, statt in Spalten vorgenommen.
Die Quadratsumme der Zellen soll im folgenden näher untersucht werden.
Man könnte annehmen, dass sich diese als Summe der Quadratsummen für
den Faktor A (QSA ) und der Quadratsumme für den Faktor B (QSB ) ergibt.
Die QSA is dabei offensichtlich mit mit der bei der einfaktoriellen Varianzanalyse bestimmten Treatmentquadratsumme identisch.
Für das Beispiel gilt: QSA = 56
QSB ergibt sich, indem für jede B-Stufe die quadrierten Abweichungen des
Mittelwertes der B-Stufe vom Gesamtmittelwert G ermittelt und aufsummiert werden.
In dem speziellen Fall: QSB = 6 · (9,83 − 10)2 + 6 · (10,17 − 10)2 ≈ 0,35
Die Summe der beiden Quadratsummen nennt man auch Quadratsumme
der Haupteffekte. Für sie gilt:
QSA + QSB = 56 + 0,35 = 56,35 6= 59 = QSZellen
Offensichtlich ist die Quadratsumme der Zellen also durch einen Faktor beeinflusst, der nichts mit den beiden Haupteffekten A und B zu tun hat.
Aus diesem Grund führt man eine weitere Quadratsumme die sogenannte
Quadratsumme der Interaktion QSA×B ein. Um diese zu Berechnen
verfolge man zunächst folgende Überlegung. Wären die Zellenmittelwerte
nur von den beiden Faktoren A und B abhängig, so müssten für sie folgende
Gleichung gelten:
0
AB ij = Ai + B i − Gi
Der tatsächliche Mittelwert AB ij ist jedoch davon abweichend.
0
In dem Beispiel wäre etwa AB 11 = 7 + 9,83 − 10 = 6,83, der tatsächliche
Zellenmittelwert jedoch AB 11 = 6,5.
Die quadrierte Abweichung dieser beiden Werte wird dann als ”Quadratsumme der Interaktionen” bezeichnet.
In dem konkreten Fall gilt:
QSA×B = 2 · (6,83 − 7,5)2 + 2 · (7,17 − 6,5)2 + 2 · (10,83 − 10,5)2 + 2 · (11,17 −
11,5)2 + 2 · (11,83 − 11,5)2 + 2 · (12,17 − 12,5)2 ≈ 2,65
Wie bei der einfaktoriellen Varianzanalyse gibt es auch bei den Quadratsummen der zweifaktoriellen Varianzanalyse einige Abhängigkeiten:
QStot = QSZellen + QSF ehler
QSZellen = QSA + QSB + QSA×B
Zieht man beide Gleichungen zusammen, so erhält man:
QStot = QSA + QSB + QSA×B + QSF ehler
114
2.2.3
Varianzschätzung und Freiheitsgrade
Um die gefundenen Quadratsummen in Varianzen überführen zu können,
ist es notwendig sie durch die jeweiligen Freiheitsgrade zu dividieren.2 Für
die Haupteffekte berechnen sich dabei die Freiheitsgrade analog zur einfaktoriellen Varianzanalyse durch Verminderung der jeweiligen Faktorstufenanzahl
um eins, d.h es sind pro Spalte p−1 bzw. pro Zeile q −1 Werte frei variierbar.
Formell: dfA = p − 1, dfB = q − 1 und dfA×B = (p − 1) · (q − 1)
Für das Beispiel ergibt sich dfA = 2, dfB = 1 und dfA×B = 2.
Daraus ergeben sich folgende Varianzschätzungen:
2
A
σ
bA2 = QS
= 28 = σ
btreat
(einfaktorielle Analyse)
= 56
dfA
2
QSB
= 0,35
= 0,35
dfB
1
QS
A×B
2
= dfA×B
σ
bA×B
= 2,65
≈
2
σ
bB2 =
1,33.
Für die Bestimmung der Freiheitsgrade dfF ehler betrachte man noch einmal
das Verfahren zur Bestimmung von QSF ehler . Hier wurden die quadrierten
Abweichungen vom jeweiligen Zellenmittelwert berechnet. Da die Summe
aller Abweichungen wieder Null ergeben muss, sind insgesamt n − 1 Werte
pro Zelle frei variierbar. Bei insgesamt p · q Zellen sind das p · q · (n − 1)
variierbare Werte.
Konkret: dfF ehler = p · q · (n − 1) = 3 · 2 · (2 − 1) = 6
Für die Varianzschätzung bedeutet dies:
F ehler
= 63 = 0,5
σ
bF2 ehler = QS
dfF ehler
Es fällt auf, dass Fehlervarianz σ
bF2 ehler im Vergleich zur einfaktoriellen Analyse (b
σF2 ehler = 0,67) kleiner geworden ist. Das bedeutet, dass in der Fehlervarianz der einfaktoriellen Varianzanalyse Anteile enthalten waren, die auf
die Unterscheidung des Faktors B im zweifaktoriellen Fall – also auf eine
geschlechtsspezifische Unterscheidung – zurückzuführen sind.
Für die weitere Bestimmung von dftot gilt analog zur einfaktoriellen Varianzanalyse der Bezug dftot = p · q · n − 1 = 3 · 2 · 2 − 1 = 11.
Ferner gilt der bereits bei der totalen Quadratsumme (QStot ) aufgefallene
Zusammenhang:
dftot = dfA + dfB + dfA×B + dfF ehler
2
2
Auf die Berechnung von dfZellen bzw. σ
bZellen
sei an dieser verzichtet, da sie für die
weitere Interpretation nicht relevant sind
115
Grundlagen
2.2.4
Nullhypothesen
Bei der zweifaktoriellen Varianzanalyse gibt es mehrere voneinander unabhängige Nullhypothesen:
1. Die Mittelwertparameter des Faktors A unterscheiden sich nicht
(H0 : µ1 = µ2 = · · · = µp )
2. Die Mittelwertparameter des Faktors B unterscheiden sich nicht
(H0 : µ1 = µ2 = · · · = µp )
3. Die Mittelwertparameter setzen sich aus den Haupteffekten zusammen.
Es besteht keine Interaktion. (H0 : µij = µi + µj = µ)
2.2.5
Signifikanztests
Die drei verschiedenen Nullhypothesen können getestet werden, indem die
entsprechenden Varianzen durch die Fehlervarianz dividiert werden. Hierzu
wird wiederum der von dem Verfahren der einfaktoriellen Varianzanalyse
bekannte F -Test verwendet. Man berechnet für die drei Hypothesen jeweils den entsprechenden F -Wert und vergleicht diesen mit den für ein bestimmtes Signifikanzniveau kritischen F -Werten aus speziellen, dafür vorgesehenen Tabellen.
Es ergibt sich:
FA =
FB =
2
σ
bA
2
σ
bF ehler
2
σ
bB
2
σ
bF ehler
2
σ
bA×B
2
σ
bF ehler
FA×B =
=
28
0,5
=
0,35
0,5
=
= 56
= 0,7
1,33
0,5
= 2,66
Der für das 1%-Niveau kritische F -Wert für den Faktor A ist aufgrund der
gleichen Freiheitsgrade mit dem kritischen F -Wert für die Interaxtion A × B
identisch.
Er lautet: F2,6;99% = 10,9
Da auch hier der empirische F -Wert des Haupteffektes A größer ist als der
kritische F -Wert, kann dessen Nullhypothese verworfen werden. Die drei
Behandlungsformen unterscheiden sich signifikant. Eine Betrachtung des
Haupteffektes B bzw. der Interaktion A × B erfolgt analog und soll an
dieser Stelle nicht näher beschrieben werden.
2.2.6
Varianzaufklärung
Auch bei der zweifaktoriellen Varianzanalyse ist es möglich, die prozentualen
Unterschiedlichkeiten der Quadratsummen der beiden Haupteffekte bzw. der
116
Quadratsumme der Interaktion zur totalen Quadratsumme zu ermitteln.
Allgemein gilt:
QSA
Faktor A: QS
· 100%
tot
Faktor B:
QSB
QStot
· 100%
Interaktion A × B :
QSA×B
QStot
· 100%
Auf das Beispiel bezogen ergeben sich folgende Werte:
Faktor A: 90,32%; Faktor B: 0,56%; Interaxtion A × B: 4,29%
2.2.7
Interaktionsdiagramme
Um die Interaktionen besser diskutieren zu können werden vielfach sogenannte Interaktionsdiagramme angefertigt. Sie bestehen aus einem
Koordinatensystem, auf dessen x-Achse der Faktor mit der größeren Stufenzahl liegt. Die y-Achse beschreibt die Werte der abhängigen Variable, also
die Mittelwerte aus der Kombination der beiden Faktorstufen. Die Werte
des zweiten Faktors (der nicht auf der x-Achse aufgetragen ist) sind in das
Koordinatensystem eingetragen und durch Linien innerhalb der Faktorstufe
verbunden. Nicht parallel verlaufende Linienzüge – wie im folgenden Fall –
weisen auf eine Interaktion der beiden Faktoren hin.
Interaktionsdiagramm des beschriebenen Beispiels:
13
12
11
10
9
8
7
6
6
weiblich
×
× •
•
männlich
•
×
-
A
2.3
B
C
Drei- und Mehrfaktorielle Varianzanalyse
Neben der Untersuchung des Effektes zweier unabhängiger Variablen auf eine
abhängige Variable ist auch eine Varianzanalyse mit mehreren unabhängigen Variablen denkbar. Dieses Kapitel soll diese Vorgehensweise anhand
117
Grundlagen
der Beschreibung einer dreifaktoriellen Varianzanalyse kurz behandeln. Für
höherfaktorielle Varianzanalysen verläuft die Berechnung entsprechend analog.
2.3.1
Terminologie
Für die Durchführung der dreifaktoriellen Varianzanalyse gelte folgende Konvention:
• Faktor A hat p Stufen (Laufindex i)
• Faktor B hat q Stufen (Laufindex j)
• Faktor C hat r Stufen (Laufindex k)
Dabei sind p · q · r Stichproben der Größe n von Nöten, so dass insgesamt
p · q · r · n Messwerte untersucht werden.
2.3.2
Die dreifaktorielle Varianzanalyse zerlegt nun die totale Quadratsumme in
drei Haupteffekte (A, B und C), drei Interaktionseffekte (A×B, B×C, A×C),
eine Interaktion zweiter Ordnung (A × B × C = ”Tripelinteraktion”) und
Fehlereffekte.
Auf die genaue Berechnung der einzelnen Quadratsummen und Freiheitsgrade sei an dieser Stelle verzichtet, da sie völlig analog zur ein- und zweifaktoriellen Varianzanalyse verläuft.
Festzuhalten bleibt jedoch folgender Zusammenhang:
QStot = QSA +QSB +QSC +QSA×B +QSA×C +QSB×C +QSA×B×C +QSF ehler
Entsprechend analog für die Freiheitsgrade:
dftot = dfA + dfB + dfC + dfA×B + dfA×C + dfB×C + dfA×B×C + dfF ehler
2.3.3
Nullhypothesen und Signifikanztest
Da die Quadratsummenzerlegung insgesamt sieben verschiedene Quadratsummen geliefert hat, ergeben sich auch sieben verschiedene Nullhypothesen:
118
3 Versuchspläne mit Messwiederholungen
Faktor A:
Faktor B:
Faktor C:
Interaktion
Interaktion
Interaktion
Interaktion
µ1 = µ2 = · · · = µp
µ1 = µ2 = · · · = µq
µ1 = µ2 = · · · = µr
A × B: µij = µi + µj − µ
A × C: µik = µi + µk − µ
B × C: µjk = µj + µk − µ
A × B: µijk = µij + µik + µjk − µi − µj − µk + µ
Die Überprüfung der sieben Nullhypothesen erfolgt wie üblich durch
F-Tests. Dabei werden die entsprechend zur Berechnung notwendigen
Varianzen durch Division der Quadratsummen durch die jeweiligen Freiheitsgrade bestimmt.
3
Versuchspläne mit Messwiederholungen
Dieses Kapitel beschreibt die Erweiterung der normalen Varianzanalyse - wie
sie bisher vorgestellt wurde - durch Wiederholungen der Messungen.
3.1
Motivation
Manchmal ist es von Interesse nicht nur einen Messwert je Versuchsobjekt
zu untersuchen, sondern mehrere Messwerte zu nehmen. In dem Beispiel
der Behandlung mit Medikamenten wäre es beispielsweise interessant, einen
”Gesundheitswert” vor, während und nach der Behandlung zu messen.
Außerdem haben Versuchspläne mit Messwiederholungen den Vorteil, dass
man durch die Variation der Faktorstufen innerhalb der Versuchsobjekte
die Anzahl an benötigten Versuchsobjekten reduzieren kann, was zu Zeitund/oder Geldersparnis führen kann. Auch die Fehlervarianz kann reduziert
werden, indem die Versuchsobjekte durch geschickte Variation von der Fehlervariation separiert werden.
3.2
Einfaktorielle Varianzanalyse mit Messwiederholungen
Bei der einfaktoriellen Varianzanalyse mit Messwiederholungen werden
allgemein n Versuchsobjekte unter p Faktorstufen ausgewertet:
119
Grundlagen
Versuchsobjekte
1
2
..
.
Faktorstufen
1
2
···
x11 x12 · · ·
x21 x22 · · ·
..
..
.
.
m
..
.
n
Summen:
xm1
..
.
xn1
A1
xm2
..
.
xn2
A2
···
···
···
i
x1i
x2i
..
.
···
···
···
p
x1p
x2p
..
.
Summen
P1
P2
..
.
xmi
..
.
xni
Ai
···
xmp
..
.
xnp
Ap
Pm
..
.
Pn
G
···
···
Hierbei beschreibt Ai die Summer aller Messwerte der Faktorstufe i, Pm die
Summe aller Messwerte des Versuchsobjektes m und G die Gesamtsumme
aller Messwerte.
Die Nullhypothese ist wieder H0 : µ1 = µ2 = · · · = µp und besagt, dass
sich Messwerte des Versuchsobjektes pro Faktorstufe nicht verändern.
Die totale Quadratsumme QStot wird hier in einen Anteil, der nur
auf den Unterschieden zwischen den Versuchsobjekten basiert (QSzw ),
und einen Anteil, welcher Veränderungen innerhalb der Messwerte eines
Versuchsobjektes beschreibt (QSin ), unterteilt.
QStot = QSzw + QSin
Die QSin ist nun weiter unterteilbar in einen Teil, der auf Treatmenteffekte
zurück geht (QStreat ), und einen zweiten Teil, welcher Interaktions- und
Fehlereffekte enthält. Die letzten beiden können zur sogenannten ”Residualquadratsumme” (QSres ) zusammengefasst werden, so dass zusammenfassend gilt:
QSin = QStreat + QSres
Einen Überblick über die Zerlegung der einzelnen Quadratsummen bietet
folgendes Schema:
Totale Quadratsumme (QStot )
Zwischen den
Versuchsobjekten (QSzw )
Innerhalb der
Versuchsobjekte (QSin )
Zwischen den
Faktorstufen (QStreat )
Residual (QSres )
Die wichtigste Fragestellung bei der Untersuchung einer einfaktoriellen Varianzanalyse mit Messwiederholungen ist die, wie die Unterschiede innerhalb
120
3 Versuchspläne mit Messwiederholungen
der Messwerte eines Versuchsobjektes zustande kommen. Insbesondere die
Treatmenteffekte sind im Hinblick darauf interessant.
Die Bestimmung der Freiheitsgrade kann direkt aus obigem Schema
abgeleitet werden. Die insgesamt p · n − 1 vorhandenen Freiheitsgrade, teilen
sich dabei wie folgt auf:
(n − 1) Freiheitsgrade für die QSzw , da für n Versuchsobjekte (n − 1) variierbare Werte vorhanden sind. Für die QSin bleiben somit n · (p − 1) Freiheitsgrade übrig, was der Variation von n Versuchsobjekten bei p−1 Faktorstufen
entspricht. Dabei ist die Treatmentquadratsumme QStreat – wie aus vorherigen Überlegungen zur Varianzanalyse ohne Messwiederholungen bekannt –
mit einem Anteil von p − 1 Freiheitsgraden vertreten. Für die QSres bleiben
nach mathematischer Umformung (n − 1) · (p − 1) Freiheitsgrade.
Die Varianzen berechnen sich dann wie gewohnt als Differenz der Quadratsummen und Freiheitsgrade. Für feste Stufen des Treatmentfaktors kann
ein Signifikanztest erstellt werden, der die Nullhypothese durch folgenden
F-Bruch überprüft:
σ
b2
F = treat
2
σ
bres
3.3
Mehrfaktorielle Varianzanalyse mit
Messwiederholungen
Bei der mehrfaktoriellen Varianzanalyse mit Messwiederholungen (hier:
zweifaktoriell) werden im Vergleich zur einfaktoriellen Version die Stichproben noch nach den Stufen eines zweiten Faktors unterteilt:
a1
a2
..
.
b1
S1
S2
..
.
b2
S1
S2
..
.
···
···
···
bj
S1
S2
..
.
···
···
···
bq
S1
S2
..
.
ai
..
.
Si
..
.
Si
..
.
···
Si
..
.
···
ap
Sp
B1
Sp
B2
···
···
Sp
Bj
···
···
Si
..
.
Sp
Bq
A1
A2
..
.
Ai
..
.
Ap
G
Hierbei beschreiben die Si jeweils Stichproben, die den p Stufen des Faktors
A (”Gruppierungsfaktor”) zugeordnet werden. Diese Stichproben werden
zusätzlich unter den q Stufen des Faktors B (”Messwiederholungsfaktor”)
beobachtet.
Auch bei der Quadratsummenzerlegung im Fall der zweifaktoriellen
121
Grundlagen
Varianzanalyse mit Messwiederholungen wird die totale Quadratsumme
QStot wieder auf zwei Quadratsummen aufgeteilt: Zum einen auf die
Quadratsumme, welche Unterschiede zwischen den einzelnen Versuchsobjekten beschreibt (QSzw ), und zum anderen auf die Quadratsumme, welche
Unterschiede innerhalb eines Versuchsobjektes beinhaltet (QSinV ).
QStot = QSzw + QSinV
Für die QSzw kann im Gegensatz zum einfaktoriellen Fall auch hier eine
weitere Unterteilung vorgenommen werden, denn die totale Quadratsumme
setzt sich aus einem Anteil QSA , welcher auf Unterschiede zwischen den
Stufen des Faktors A beruht, und einem Anteil QSinS , welcher Unterschiede
innerhalb der Stichproben eines Versuchsobjektes beschreibt, zusammen.
QSzw = QSA + QSinS
Für die Unterschiede in den Messwerten eines einzelnen Versuchsobjektes
sind neben der Quadratsumme des Faktors B (QSB ) auch die Interaktion von
A und B (QSA×B ) sowie die spezifische Reaktionsweise des Versuchsobjektes
auf die Stufen von B (QSB×V ) verantwortlich.
QSinV = QSB + QSA×B + QSB×V
Einen Überblick über die Zerlegung der einzelnen Quadratsummen bietet
folgendes Schema:
Totale Quadratsumme (QStot )
Zwischen den
Versuchsobjekten (QSzw )
Faktor A (QSA )
Innerhalb der
Versuchsobjekte (QSin )
Faktor B (QSB )
Innerhalb der
Stichproben (QSinS )
Interaktion A × B
(QSA×B )
Interaktion B × V
(QSB×V )
Für die Signifikanztests werden nun wieder in gewohnter Weise die
Quadratsummen durch ihre Freiheitsgrade dividiert. Unter der Annahme,
dass A und B feste Effekte sind, können folgende Beziehungen getestet werden:
2
σ
bA×B
σ
bA2
σ
bB2
,
,
2
2
2
σ
binS
σ
bB×V
σ
bB×V
122
5 Quellen
4
Zusammenfassung und Fazit
Die ein- bzw. mehrfaktorielle Varianzanalyse ist ein Verfahren, das die
Wirkung einer oder mehrerer unabhängiger Variablen auf eine abhängige
Variable untersucht. Besonders beim Vergleich von großen Datenmengen
kann die Varianzanalyse ihre Vorteile (keine α-Kumulierung und große Teststärke) gegenüber anderen Verfahren wie beispielsweise dem t-Test ausspielen. Doch auch die Varianzanalyse hat Einschränkungen. So kann eine Untersuchung nur für ein abhängige Variable in Intervallskalenqualität gewährleistet werden. Für Messungen auf Ordinal- oder Nominalskalenniveau gibt
es gesonderte Verfahren. Auf eine Verletzung anderer Kriterien (z.B. Normalverteilung der Stichproben) reagiert die Varianzanalyse hingegen weitestgehend robust und liefert dennoch in der Regel brauchbare Ergebnisse. Insbesondere die mehrfaktorielle Varianzanalyse (sowohl im Fall ohne Messwiederholungen als auch im Fall mit Messwiederholungen) eignet sich hervorragend für explorative Untersuchungen (Erkundungsuntersuchungen) im
Bereich der Softwaretechnik. Durch die Möglichkeit Interaktionen zwischen
den Haupteffekten zu untersuchen können so nämlich z.B. mögliche Einflüsse
auf gefundene Defekte in einem eingebetteten System analysiert werden. Man
spricht daher im Bezug auf mehrfaktorielle Versuchspläne auch von ”faktoriellem Design”.
5
Quellen
• Bortz, J.: Statistik. 4. Auflage. Springer, 1993.
• Rasch, B.: Quantitative Methoden, Bd. 2. Springer, 2004.
• Glaser, W.: Varianzanalyse. Fischer, 1978.
• Gediga, G.: Varianzanalysen.
http://www.psycho.uni-osnabrueck.de/ggediga/www/pm98/pages/
anova.htm
• Jacobs, B.: Mehrfaktorielles Design.
http://www.phil.uni-sb.de/ jakobs/seminar/vpl/mehrfak/mehrfak.htm
123
Kritik in der Statistik
Jörg Toborg
Grundlagen
1
Einführung
Das Gebiet der Statistik ist breit gefächert und bietet etliche Ansatzpunkte
für Kritik. Diese Ausarbeitung geht auf ”alltägliche” Manipulationen und
Gefahren ein, die ein zu gutgläubiger Umgang mit Zahlen und Statistiken mit
sich bringen kann. Gerne wird von Lügen gesprochen die eigentlich keine sind,
denn die Kritik beschränkt sich meist auf zielgerichtete Darstellungen von
Fakten, die eher einem Betrug gleich kommen. Es wird nicht versucht Zahlen
sachlich und ehrlich darzustellen, sondern künstliche Vorteile erzeugt, die
mit der Wahrheit nicht übereinstimmen. Einen kleinen Trost direkt vorweg:
Falsche Zahlen sind meist leichter zu erkennen als falsche Worte oder falsche
Bilder und ohne eigene Begünstigung muss sich niemand für dumm verkaufen
lassen, denn auch statistische Lügen haben kurze Beine [1].
2
Vorsicht mit Prozentangaben
Die allseits beliebten Prozentangaben, mit denen man tagtäglich bombadiert
wird, werden häufig überschätzt. Stehen sie doch für Glaubwürdigkeit
und Autorität, Prozente strahlen Gewißheit aus, attestieren einem Rechenfähigkeiten, verleihen Autorität und Überlegenheit. Viele Leute wissen gar
nicht damit umzugehen. Laut einer Umfrage des Emnid-Instituts sind rund
ein Drittel der Deutschen nicht in der Lage die Angabe ”40 Prozent” richtig
zu deuten. Bei einer Umfrage des ”Office of Fair Trading” antworteten auf
die Frage ”Wieviel sind 40 Prozent?” sogar rund die Hälfte aller befragten
Bankkunden mit ”einer von 40” oder ”ein Viertel”. Dieser Wert ist Besorgnis
erregend, wenn man bedenkt wie häufig Prozentangaben heutzutage benutzt
werden und wieviel Beachtung man diesen zukommen lässt.
Aber auch ohne diese Unwissenheit kann man eine Menge Schabernack
mit Prozentangeben treiben. ”Aufklärungsquote von 104 Prozent” meldet
die Jenaer Polizei (geschrieben in der Welt). ”Mehr Mörder als die Jenaer
Polizei fängt niemand: 104,8 Prozent aller Fälle von Mord, Mordversuch
und Tötung klärten die Beamten 1993 auf”. Der Grund dafür lag in der
Rechnung der Polizisten. Diese teilten die in einem Jahr geklärten Fälle
durch die im gleichen Jahr gemeldeten Fälle. Mit solchen Vorgehensweisen
sind Quoten beliebig zu verbessern. Wird in einem Jahr ein Mord begangen
und drei alte aufgeklärt, so gibt es demzufolge eine Aufklärungsquote von
300 Prozent...
Doch auf Fachleute wissen Prozentangeben gelegentlich nicht richig
einzuordnen. Laut [4] unterliegen gerade Ärzte und ihre Patienten häufig der
126
2 Vorsicht mit Prozentangaben
verhängnisvollen Illusion von absoluter Gewissheit. Fehler, aufgrund einer
Fehleinschätzung von Prozentangaben, sind in der Medizin keine Seltenheit.
Viele moderne und vergleichsweise zuverlässige Diagnose- und Therapieverfahren sind weitaus weniger sicher, als sie auf den ersten Blick erscheinen. [5]
geht in seinem Buch auf den HIV-Test (ELISA) ein. Dieses Verfahren erkennt
Kranke und Gesunde mit einer Wahrscheinlichkeit von 99,99 Prozent. Es gibt
also bei einem von 10.000 Gesunden fälschlich einen positiven Befund. Folgt
daraus auch, dass man bei einem positiven HIV-Test mit 99,99-prozentiger
Sicherheit davon ausgehen kann, das Aids-Virus zu haben?
Keinesfalls, denn entscheidend für die Einschätzung eines ”positiven” Befundes4 ist die Verbreitung der
Infektion.
Als Beispiel: Von 10.000 heterosex2 Vorsicht
mit Prozentangaben!
uellen Männern , die keiner Risikogruppe angehören, ist statistisch gesehen
lediglich einer infiziert. Bei 10.000 Tests wird man also zwei HIV-Kranke erKeinesfalls,
entscheidend
für die
Einschätzung
eines
positiven“
mitteln,
dabeidenn
jedoch
einen Mann
fälschlich
positiv
testen
- da jaBefunim Durch”
des ist die Verbreitung der Infektion. Als Beispiel: Von 10.000 heterosexuellen
schnitt mit einer Fehldiagnose zu rechnen ist. Das bedeutet aber: Jeder
Männern , die keiner Risikogruppe angehören, ist statistisch gesehen lediglich
zweite
HIV-Test
beiwird
Nicht-Risikogruppen
ist ein
Fehlalarm
einer positive
infiziert. Bei
10.000 Tests
man also zwei HIV-Kranke
ermitteln,
dabei - die
Wahrscheinlichkeit,
bei einem
positiven
infiziert
sein, bejedoch einen Mann fälschlich
positiv
testenTest
- da tatsächlich
ja im Durchschnitt
mitzu
einer
Fehldiagnose
zu
rechnen
ist.
Das
bedeutet
aber:
Jeder
zweite
positive
HIV-Test
trägt nur 50 Prozent! Selbst für viele Mediziner ist das ein überraschendes
bei Nicht-Risikogruppen
ein Fehlalarm
- diedie
Wahrscheinlichkeit,
bei einembringt,
Ergebnis,
denn auch beiist
allem
Nutzen den
Statistik der Medizin
positiven Test tatsächlich infiziert zu sein, beträgt nur 50 Prozent! Selbst für viebleiben
etliche Unsicherheiten im Umgang mit ihr, die im schlimmsten Fall
le Mediziner ist das ein überraschendes Ergebnis, denn auch bei allem Nutzen
zu den
Lasten
der Patienten
gehen.
die Statistik
der Medizin
bringt, bleiben etliche Unsicherheiten im Umgang
mit ihr, die im schlimmsten Fall zu Lasten der Patienten gehen.
10.000 Männer
1 HIV
1 positiv
0 negativ
9.999 kein HIV
1 positiv
9.998 negativ
Figure 1: Was bedeutet ein positiver HIV-Test wirklich? Von 10.000
Fig.
1: Was bei
bedeutet
einkeine
positiver
HIV-Test
wirklich? Von
10.000 Männern,
Männern,
denen
riskante
Lebensweise
bekannt
ist, werden
bei denen
keine riskantezwei
Lebensweise
ist,und
werden
durchschnittlich
zwei
durchschnittlich
positivbekannt
getestet,
einer
von ihnen wird
positiv getestet, und einer von ihnen wird HIV-infiziert sein.
HIV-infiziert sein.
Immerhin lässt sich bei diesem Testverfahren die Trefferwahrscheinlichkeit
Immerhin
lässt
sichistbei
Testverfahren
die Trefferwahrscheinlichkeit
angeben.
Grund
dafür
diediesem
bekannte
Zahl der insgesamt
Infizierten in Deutschangeben.
Grund
ist die sobekannte
Zahl
insgesamtgar
Infizierten
in
land. Ist diese
Zahldafür
nicht bekannt,
kann, wie im
Fallder
des BSE-Tests,
nichts
darüber gesagt werden wie verlässlich der Test ist. Im Klartext bedeutet dies
das niemand
ob die 387 Softwaretechnik
Rinder, die seit dem Jahre 2000 in Deutschland als 127
Methoden
derweiß,
empirischen
bestätigte BSE-Fälle gesehen werden (Quelle: www.verbraucherministerium.de
Stand 28.10.05), tatsächlich BSE krank waren, oder fälschlicherweise als krank
gestestet wurden. Fakt ist nur, dass im Zeitraum 01.01.2001 - 31.10.2005 in
Deutschland insgesamt 12.472.655 Rinder auf BSE untersucht wurden. Wie so
oft ist hier das entscheidende die Bevölkerung zu beruhigen und als Regierung
Handlungsfähigkeit zu demonstrieren. Fehlende Kenntnis über die Aussagekraft
bzw. Verlässlichkeit eines solchen Testverfahrens sind dabei zweitrangig.
Grundlagen
Deutschland. Ist diese Zahl nicht bekannt, so kann, wie im Fall des BSETests, gar nichts darüber gesagt werden wie verlässlich der Test ist. Ob die
387 Rinder, die seit dem Jahre 2000 in Deutschland als bestätigte BSE-Fälle
gesehen werden (Quelle: www.verbraucherministerium.de Stand 28.10.05),
tatsächlich BSE krank waren, oder fälschlicherweise als krank gestestet
wurden, bleibt Vermutung. Fakt ist nur, dass im Zeitraum 01.01.2001 31.10.2005 in Deutschland insgesamt 12.472.655 Rinder auf BSE untersucht
wurden.
Ein weiteres Beispiel für Irreführung durch entsprechend dargestellte Zahlen
ist das von Ulla Schmidt, amtierende Gesundheitsministerin, geforderte bundesweite Brustkrebs-Screening. Regelmäßige Röntgenchecks, so die Aussage, würden die Brustkrebstodesrate von Frauen über 50 Jahren um fast
ein Drittel reduzieren. Faktisch ist diese Aussage nicht zu bezweifeln, nur
fällt bei genauer Betrachtung der Zahlen auf, dass sich der Nutzen auch anders darstellen lässt. Stünde der Nutzen der Patientinnen im Vordergrund,
so wäre eine informative Aufklärung vorteilhaft. Brustkrebs ist eine relativ seltene Krankheit, an der ohne Früherkennungsuntersuchungen jedes
Jahr etwa 14 von 1000 Frauen in der gefährdeten Altersgruppe sterben.
Mammographie-Screenings können die Zahl der Brustkrebsopfer auf 10 reduzieren. Daher haben effektiv nur 4 von 1000 Frauen, also 0,4 Prozent,
einen Nutzen davon, was weit weniger beeindruckend ist. Die Entscheidung über Sinn und Nutzen der Untersuchung sollte also den Betroffenen
selbst überlassen werden. Was zudem laut [4] gerne verschwiegen wird, dass
durch falsch-positive Mammogramme allein in Deutschland jährlich rund
300.000 Frauen monatelang in Angst und Schrecken versetzt werden und
sich schätzungsweise 100.000 von ihnen, in Folge dessen, kleinen Operationen unterziehen.
Prozentangaben, die ohne Angabe der Bruchrechnung auskommen, durch die
sie zustande gekommen sind, sind vorsichtig zu betrachten und erwecken den
Eindruck als hätte der Urheber etwas zu verbergen. Aussagekräftiger ist in
jedem Fall eine Angabe der kompletten Rechnung.
Prozente täuschen oft auch bei Wachstumsraten. Denn diese werden
gerne mit Wachstumsraten von Wachstumsraten in einen Topf geworfen.
Angenommen eine Firma machte folgende Umsätze: 100 101 102,5. Dann
ergibt sich ein relativ schwaches Umsatzwachstum von zunächst einem
Prozent im ersten Jahr und 1,5/101 = 1,49 Prozent im zweiten Jahr. Werden
die Zahlen dagegen in Wachstumsraten von Wachstumsraten angegeben, so
wächst das Umsatzwachstum um stolze 49 Prozent. Mathematisch eine einwandfreie Rechnung, die dennoch die Realitäten auf den Kopf stellt. Unter
einer Steigerung des Umsatzwachstums von fast 50 Prozent stellt man sich
doch eine dynamischere Entwicklung als die der Beispielzahlen vor.
128
3 Median und Mittelwert
3
Median und Mittelwert
Im Allgemeinen wird der Durchschnitt mit dem arithmetischen Mittel
angegeben. Hat Hörsaal A beispielsweise 50 Sitzplätze und Hörsaal B 150
Sitzplätze, so hat im Durchschnitt jeder 100 Sitzplätze. Dafür wird die
Summe der Sitzplätze geteilt durch die Anzahl der Hörsääle. Leicht zu
rechnen verdichtet es große Datenmengen elegant zu einer Zahl. Der Nachteil
liegt in der Unterschlagung von großen Ungleichheiten und nimmt keinen
Bezug zur Streuung um die Mitte. Besitzt in einem Dorf mit zehn Bauern
einer 40 Kühe und alle anderen haben nichts, so hat im Durchschnitt jeder
vier Kühe. Ein schwacher Trost für die neun die keine Kühe haben. Extreme Werte werden voll berücksichtigt, ein Bezug auf die Gleichverteilung
fehlt. Vergleicht man die mittlere Lufttemperatur zweier Orte, so hat
Plymouth/England übers Jahr gerechnet 13 Grad (Tageswerte), damit fast
das gleiche wie in Minneapolis/USA. Dennoch ist das Klima beider Orte
kaum miteinander zu vergleichen. In Plymouth schwankt die Temperatur
zwischen 8 Grad im Februar und 21 Grad im Juli. Plymouth hat also
eine bemerkenswert kleine Streuung der Temperaturen übers Jahr gesehen,
es gibt weder Frost noch große Hitze. Im Januar sinkt das Thermometer
durchschnittlich auf minus 15 Grad, im Sommer steigt es dafür auf über 30,
zuweilen sogar an die Grad 40. Zwischen den gemittelten Werten übers Jahr
gesehen gibt es dennoch keinen Unterschied. Um einen seriösen Durchschnitt
anzugeben, gehört in aller Regel auch ein Maß für die Abweichung dazu.
Mittelwerte ohne zugehörige Abweichung sind also mit Vorsicht zu geniessen.
Der große Gegenspieler des, für die meisten Zwecke völlig ausrechenden
Mittelwerts, ist der Zentralwert oder Median. Etwas grob gesagt ist damit
die Zahl gemeint, die genauso viele linke wie rechte Nachbarn hat. Sind die
Daten vorsortiert, so wählen wir immer genau das Element in der Mitte. Er
ist einfacher zu finden als das arithmetische Mittel und hat noch weitere
Vorteile. Er kann nur Werte annehmen, die auch tatsächlich vorkommen,
z.B. gibt es keine Durchschnittsfamilien mit 1,7 Kindern oder 3 1/2 Sexualpartner pro Bundesbürger, auch wenn solche Angaben immer wieder gerne
von Statistikern zur Erheiterung des Publikums genutzt werden. Ein zweiter
Vorteil kann sein, das tatsächlich die Hälfte aller Werte über und unter dem
Median liegen, was häufig fälschlicherweise auch dem Mittelwert unterstellt
wird. Beim Mittelwert kann das der Fall sein, muss aber nicht.
Ein weiterer großer Vorteil des Medians ist seine Unanfälligkeit gegenüber
Ausreißern. Meß- oder Eingabefehler fallen weniger stark ins Gewicht
und beeinflussen das Ergebnis entsprechend nur um die Anzahl linker
oder rechter Nachbarn. Pro Eingabe kann sich der Median maximal um
129
Grundlagen
eine Stelle von der tatsächlichen Mitte verschieben. Wird hingegen beim
arithmetischen Mittel ein fehlerhafter Wert gemessen, der womöglich einen
Fehler im Exponenten hat, wird das Ergebnis dadurch viel stärker beeinflusst.
Figure 2: aus [1]
Ist sich der Autor eines Berichts darüber im Klaren wo die Vor- bzw.
Nachteile liegen, so können diese ganz gezielt eingesetzt werden. Die Vorund Nachteile sind abhängig vom Standpunkt des Betrachters, sowie vom
Vorkommen der Ausreißerwerte. Treten kleine Werte häufig auf und große
immer seltener, spricht der Statistiker von ”schief verteilt” (genauer: rechtsschief). Typische Beispiele dafür sind Merkmale wie Einkommen, Vermögen
oder Grundbesitz. Je größer der Wert, desto seltener kommt er vor. Bei
solchen Merkmalen liegt das arithmetische Mittel immer oberhalb des Median, manchmal sogar sehr weit darüber. Die vorteilhafte Verwendung ist
naheliegend, hätte man den Durchschnitt gerne etwas höher, so verwendet
man das arithmetische Mittel, ist man dagegen eher an niedrigen Werten
interessiert, so ist der Median die bessere Darstellungsweise. Normalerweise
wird nicht weiter nachgefragt um welchen Durchschnitt es sich handelt, dabei
wäre das häufig eine sehr interessante Frage. Wie gesagt wird dem Durchschnitt unterstellt, er sei das arithmetische Mittel, dem muss aber nicht so
sein und häufig kann der Median viel aussagekräftiger sein.
Handelt es sich bei dem Auftreten von großen und kleinen Werten dage130
3 Median und Mittelwert
gen um eine links-schiefe Verteilung, also viele große Werte und kleine immer
seltener, so ist der Verwendung der beiden Durchschnitte entsprechend umgedreht.
3.1
Gewichtete Mittelwerte
Eine weitere Unterscheidung die man treffen muss ist zwischen gewöhnlichem artihmetischen Mittel und dem ”gewogenen” oder ”gewichteten”
arithmetischen Mittel. Wird beispielsweise der Durchschnittslohn einer
Firma ermittelt, so gibt dafür zwei Möglichkeiten. Zum einen kann man
die Löhne aller auftretenden Lohnklassen aufaddieren und durch die Anzahl
aller Lohnklassen teilen. Die zweite Möglichkeit ist die Lohnklassen mit der
Anzahl der Mitarbeiter zu multiplizieren, die in der jeweiligen Lohnklasse
arbeiten und die Gesamtsumme durch die Anzahl aller Arbeiter zu teilen.
Angenommen in der Softwareschmiede ”Millisoft” arbeiten 19 Programmierer mit einem Stundenlohn von 20e und ein Geschäftsführer mit einem
Stundenlohn von 50e, so beträgt der Durchschnittsstundenlohn für den
ersten Fall:
20+50
2
= 35e
Für den zweiten ergibt sich jedoch ein Stundenlohn der wesentlich
näher an der Realität liegt:
19×20+1×50
20
= 21,5e
Eigentlich ist die Verwendung der Gewichte intuitiv, Angaben mit Tendenz
zur Manipilation bedienen sich aber auch gerne der unsinnigen Variante.
Noch eine Zahl die für Diskussionsbedarf sorgt, ist die Zahl, mit der man
beim arithmetischen Mittel durch die Merkmalsumme teilt, also der Nenner
des Bruches aus dem sich das arithmetische Mittel ergibt. Ein relativ
bekanntes Beispiel ist die Verkehrssicherheit. Da das Auto unangefochten
Platz eins der unsicheren Verkehrsmittel inne hat, betrachten wir hier die
Sicherheit von Flugzeug und Bahn. Aus Erfahrung wissen die meisten
Menschen das Fliegen allgemein als das sicherste Verkehrsmittel gilt. Aller
Nachrichten abgestürzter Flugzeuge zum Trotz, steht meist noch im gleichen
Artikel das Fliegen nach wie vor das sicherste Verkehrsmittel ist. Im
Durchschnitt sterben bei Flugzeugunfällen weniger Leute als bei Unfällen
mit der Eisenbahn. Nur die wenigsten Leute machen sich Gedanken darüber
wie dieser Durchschnitt berechnet wird und welche Zahl den Nenner des
Bruches stellt, der letztlich unseren Mittelwert ergibt. Der Standard-Nenner
131
Grundlagen
sind die insgesamt zurückgelegten Passagier-Kilometer, damit ergibt sich:
Bahn:
9 Verkehrstote pro 100 Millionen Passagierkilometer
Flugzeug: 3 Verkehrstote pro 100 Millionen Passagierkilometer
So gesehen ist Bahn fahren tatsächlich dreimal so gefährlich wie mit
Flugzeug zu fliegen. Wieso befällt viele Leute dennoch die Angst beim
Besteigen eines Flugzeugs, nicht jedoch beim Besteigen eines Zuges. Ändert
man die Einheit des Nenners auf die Anzahl der Stunden die wir uns in
potenzielle Gefahr begeben, dann sieht die Statistik gleich ganz anders aus.
Ob es für den Passagier interessanter ist zu wissen wie wahrscheinlich es
ist auf den nächsten tausend Kilometern oder in der nächsten Stunde zu
Sterben bleibt dahingestellt, ihre Berechtigung hat diese Überlegung alle
mal.
Anstelle der Passagier-Kilometer stehen nun mit erstaunlichem Ergebnis die
Passagier-Stunden im Nenner. Folgende Durchschnitte ergeben sich:
Bahn:
7 Verkehrstote pro 100 Millionen Passagier-Stunden
Flugzeug: 24 Verkehrstote pro 100 Millionen Passagier-Stunden
Der Vorteil des Fliegens hat sich umgedreht - pro Stunde produziert der
Flugverkehr mehr als dreimal so viel tödliche Unfälle wie die Eisenbahn.
Anzumerken bleibt das trotz allem niemand Angst beim Besteigen seines
Bettes hat, auch wenn die Wahrscheinlichkeit, darin zu sterben, bei fast 99
Prozent liegt [1].
4
Vorsortierte Stichproben
Die Methode der Stichprobe ist weit verbreitet und ihr Nutzen unbestritten.
Es ist ausgeschlossen z.B. vor einer Bundestagswahl alle wahlberechtigten
Bürger nach ihrer Meinung zu fragen um bereits vor der Wahl ein mögliches
Ergebnis zu veröffentlichen. Hochrechnungen können aber nur dann aussagekräftig sein, wenn die befragten oder in der Stichprobe aufgenommenen
Personen auch die Gesamtbevölkerung bzw. die Gruppe aller in Frage kommenden Personen repräsentieren. So dürfte eine Stichprobe zur nächsten
Bundestagswahl, die in einem kleinen Dorf in Oberbayern durchgeführt wird,
kaum repräsentativ für die Gesamtbevölkerung sein. Befragt das Studentenwerk die Studenten in der Mensa nach ihrer Meinung zur Qualität des Essens,
132
4 Vorsortierte Stichproben
so ist auch diese Stichprobe bereits vorsortiert, da alle Stundenten, die sich
entschieden haben zu Hause oder woanders zu essen, einen erheblichen Einfluss auf das Ergebnis einer solchen Umfrage hätten. Eine solche Umfrage
nennen Statistiker verzerrt, was das Gegenteil von repräsentativ ist.
Das Ergebnis der Umfrage ist in hohem Maße davon abhängig wen man befragt. So muss es nicht verwundern, dass laut [1] ein Psychiater geschrieben
hat: ”Die ganze Menschheit ist verrückt”. Auf die Frage wie er denn darauf
käme antwortet dieser: ”Sehen sie sich doch die Leute in meiner Praxis an”.
Um möglichst viele Vorsortierungen auszuschliessen werden die Leute zufällig ausgewählt. Der Begriff Zufall ist breit gefächert. Man kann in der
Mensa zufällig Personen auswählen, dabei ist der Zufall dann aber bereits
eingeschränkt auf die Lokalität Mensa. Eine echte zufällige Auswahl muss
aber über allen in Frage kommenden Personen stattfinden. So verwenden
Meinungsforscher die Möglichkeit die Personen telefonisch auszuwählen, um
so auf repräsentative Stichproben zu kommen.
Ein unterschätztes Beispiel für Vorsortierung sind die Nachrichten aus Radio, Fernsehen und Zeitung, die immer nur eine Stichprobe aller potenziellen
Nachrichten sein können. Die Selektion der Stichprobe unterliegt dabei den
Einflüssen von Vorurteilen und Weltbildern der Redaktionen der jeweiligen
Medien und beeinflusst die Wahrnehmung eines jeden Einzelnen. Diese Vorsortierung sollte man bei der Beurteilung der täglichen Nachrichten sowie
bei der Auswahl der Medien sehr stark berücksichtigen. Der Einfluss von
einigen Verlagen und Redakteuren, der auf die Bevölkerung und damit auch
auf die öffentliche Meinung ausgeübt wird, ist immens. Berichten die Medien
nicht mehr von BSE-Fällen bei Rindern, so ist das Thema vom Tisch, auch
wenn diese nach wie vor auftreten. Natürlich spielt dabei auch das öffentliche
Interesse eine Rolle, so dass die Auswahl der Stichprobe ”leider” auch eine
Reaktion auf die Personen ist, die die Medien konsumieren. Mag das auch auf
der einen Seite, beispielsweise in der Fachpresse, vorteilhaft sein. Der Leser
der ”CT” liest ganz gezielt diese Zeitschrift, um eine Selektion von Informationen zu erhalten, die er in anderen Medien nicht bekäme. Andererseits
kann eine solche Beschränkung in den Nachrichten sowohl dazu führen ”Mord
und Totschlag” täglich auf der Titelseite zu lesen, auch wenn das nicht den
Statistiken entspricht, als auch andere Nachrichten die auf weniger Interesse
stoßen aber nicht minder relevant als andere sind, zu vernachlässigen.
Zumindest zu Verzerrungen muss man aber hinzufügen, dass diese nicht
immer mit Absicht oder Hintergedanken geschehen. Häufig kommen die
Nachrichten auch schon verzerrt in den Redaktionen an. Ursachen dafür
sind beispielsweise im Abschnitt ”Korrelation kontra Kausalität” zu finden.
Ein Grund mehr bei der Auswahl der Nachrichten ganz besondere Sorgfaltspflicht walten zu lassen.
133
Grundlagen
5
Korrelation kontra Kausalität
Einer der häufigsten Fehler, der Menschen im Umgang mit Statistiken
unterläuft, ist der falsche Schluß von Korrelation und Kausalität. Die
Annahme, das wenn zwei Variablen parallel verlaufen, die eine die andere
leitet. Das kann richtig sein, manchmal ist es aber auch falsch. So ist zum
Beispiel das Handelsblatt unter dem Stichwort ”Methusalems machen Kasse”
zu dem Schluß gekommen, dass langes Studieren ein hohes Starteinkommen
fördert. Natürlich ist das Gegenteil der Fall. ”Bummelstudenten” haben
eher bescheidene Aussichten auf eine gute Anstellung; das Startgehalt geht
in aller Regel mit steigender Semesterzahl zurück. Das Handelsblatt, dass
diese Darstellung später korregiert hat, kommt zur positiven Korrelation
von Studiendauer und Gehalt aus folgendem Grund: Sie haben alle Fächer
in einen Topf geworfen. Die Hochschulabsolventen mit den langwierigsten
Fächern, wie Chemie und Medizin, hatten die höchsten Startgehälter.
Die Begründung für die höheren Gehälter liegt jedoch in der Schwere der
Ausbildung und nicht in der Länge des Studiums. Die Länge als solche
trägt überhaupt nichts dazu bei. Ganz im Gegenteil ist ein schnellerer
Abschluss ganz klar positiv zu bewerten, nur das dieser schnelle Abschluss
entsprechend schwieriger ist.
Die kürzeren Studiendauern der Diplom-Betriebswirte (FH) runden aufgrund
eines Überangebots die Liste der Startgehälter nach unten ab. Hält man das
Studienfach als dritte Variable konstant, ist der Zusammenhang zwischen
Studiendauer und Gehalt in allen Fächern negativ.
Bei der Korrelation zwischen Rauchen und frühem Sterben tritt der
gleiche Fehler in abgeschwächter Form auf. Auch wenn es wahrscheinlich
einem guten Zweck dient, so ist die Aussage der Bundeszentrale für gesundheitliche Aufklärung, das ein 30jähriger Raucher mit einem Konsum von ein
bis zwei Päckchen Zigaretten am Tag sechs Jahre früher stirbt als ein Nichtraucher, anzufechten. Das wissenschaftliche Institut der Ortskrankenkassen
behauptet sogar es seien 12 Jahre früher. Nur zu naheliegend ist der Schluss,
dass diese Zahl alleine aufgrund des Tabakkonsums so hoch ist. Jedoch
werden Raucher öfter ermordet als Nichtraucher oder auch häufiger von
Bussen überfahren. Die Gründe dafür sind dem Tabak kaum anzulasten,
sondern vielmehr mit der Raucherpersönlichkeit zu erklären, die anscheinend
bewusst mehr gefährliche Gewohnheiten in Kauf nimmt, so dass Menschen
mit dieser Art von Persönlichkeit wohl auch gefährlicher leben würde, wäre
der Tabak niemals entdeckt worden.
Eine weitere Schreckensmeldung aus den Medien ist die von Jahr zu
134
6 Kurvendiskussion
Jahr steigende Krebsgefahr. Laut [1] ist genau das Gegenteil der Fall. Die
Wahrscheinlichkeit an Krebs zu sterben hat quer durch alle Altersklassen
und für Männer wie für Frauen gleichermaßen in den letzten dreißig Jahren
abgenommen. Der tatsächliche Grund dafür das heutzutage rund 23 Prozent
im Vergleich zu 10 Prozent zu Anfang des Jahrhunderts sterben, liegt in
einer unterschlagenen Hintergrundvariable, dem Lebensalter. Die Tatsache,
das Kaiser Wilhelms Zeitgenossen seltener Krebs bekamen, liegt nicht an
ihrem gesunden Lebenswandel, sondern daran, dass die Menschen damals
nur durchschnittliche 45 Jahre alt geworden sind und an anderen Krankheiten
gestorben sind.
Die Liste der unsinnigen Korrelationen lässt sich beliebig fortsetzen. Da
wäre noch die Anzahl der Klapperstörche, deren Zahl hoch positiv mit den
bundesdeutschen Geburten korreliert, die Zahl der unverheirateten Tanten
eines Menschen korreliert negativ mit dem Kalziumgehalt seines Skeletts,
Heuschnupfen und Weizenpreis (negative Korrelation), Schuhgröße und Lesbarkeit der Handschrift (positive Korrelation), Schulbildung und Einkommen (positive Korrelation) und nicht zu vergessen der Ausländeranteil und
die Kriminalität (positive Korrelation). Die Zahl der falsch verstandenen
bzw. absichtlich mißbrauchten Korrelationen kennt praktisch keine Grenze.
Die Gefahr, die aus manchen dieser falschen Schlussfolgerungen für das allgemeine Gedankengut auftritt, ist nicht zu unterschätzen. Beachtet werden insbesondere jene Aussagen, in denen sich jemand in seiner Angst oder
auch Vorurteilen bestätigt fühlt. Ein verantwortungsbewusster Umgang mit
solchen Aussagen sollte eigentlich selbstverständlich sein.
6
Kurvendiskussion
Die grafische Veranschaulichung von Statistiken ist der Favourit unter den
Darstellungsmethoden. Grafisch aufbereitet lassen sich große Datenmengen
meist auf einen Blick schnell Verstehen und Auswerten. Selbst hunderte
von Zahlenwerten können in kurzer Zeit erfasst und verarbeitet, Ergebnisse
so kompakt dargestellt werden. Gerade die oberflächliche Betrachtung bietet reichlich Raum zur Manipulation und wird in ihren Möglichkeiten noch
verstärkt, dadurch dass das Auge noch lange aufnahmefähig ist, wenn der
Verstand längst abgeschaltet hat. In diesem Abschnitt widme ich mich der
speziellen Darstellung mit Hilfe von Graphen.
Angenommen die Softwareschmiede ”Millisoft” möchte anlässlich ihres
10jährigem Firmenjubiläum ein Resumee herausgeben. Von Betriebserfolg
und Gewinnen kann leider keine Rede sein, der Konkursrichter ist alle zwei
Jahre zu Gast und der Firma geht es alles andere als gut. Dennoch erwartet
135
Die grafische Veranschaulichung von Statistiken ist der Favourit
11unter den Darstellungsmethoden. Grafisch aufbereitet lassen sich große Datenmengen meist
auf einen Blick schnell Verstehen und Auswerten. Selbst hunderte von Zahlenwerten können in kurzer Zeit erfasst und verarbeitet, Ergebnisse so kompakt
6 Kurvendiskussion
dargestellt werden. Gerade die oberflächliche Betrachtung bietet reichlich Raum
zur Manipulation und wird in ihren Möglichkeiten noch verstärkt, dadurch dass
Die grafische Veranschaulichung von Statistiken ist der Favourit unter den Dardas Auge noch lange aufnahmefähig ist, wenn der Verstand längst abgeschaltet
stellungsmethoden. Grafisch aufbereitet lassen sich große Datenmengen meist
Grundlagen
hat. In diesem Abschnitt widme ich mich der speziellen Darstellung mit Hilfe
auf einen Blick schnell Verstehen und Auswerten. Selbst hunderte von Zahvon Graphen.
lenwerten können in kurzer Zeit erfasst und verarbeitet, Ergebnisse so kompakt
Angenommen die Softwareschmiede Millisoft“ möchte anlässlich ihres 10jähdargestellt werden. Gerade die oberflächliche Betrachtung
bietet reichlich Raum
”
rigem Firmenjubiläum
einDarstellung
Resumee herausgeben.
Von Betriebserfolg
der Vorstand
eine
möglichst
von eventuellen
eige- und Gezur Manipulation und wirdvorteilhafte
in ihren Möglichkeiten
nochum
verstärkt,
dadurch dass
winnen
kann
leider
keine
Rede
sein,
der
Konkursrichter
ist
alle
zwei Jahre zu
nen Fehlern
abzulenken.
Das folgendeist,
Diagramm
bildet die
Umsätze
als triste
das Auge
noch lange aufnahmefähig
wenn der Verstand
längst
abgeschaltet
Gast und der Firma geht es alles andere als gut. Dennoch erwartet der Vorstand
hat. Inunverschönt
diesem Abschnitt
ich mich dereher
speziellen
Darstellung
Hilfe zu
Realitäten
ab: widme
kaum Dynamik,
Stagnation,
keinmit
Grund
eine möglichst vorteilhafte Darstellung um von eventuellen eigenen Fehlern abvon
Graphen.
viel Begeisterung. zulenken. Das folgende Diagramm bildet die Umsätze als triste Realitäten unAngenommen die Softwareschmiede Millisoft“ möchte anlässlich ihres 10jäh”
verschönt ab: kaum Dynamik,
eher Stagnation, kein Grund zu viel Begeisterung.
rigem Firmenjubiläum ein Resumee herausgeben. Von Betriebserfolg und Ge110keine Rede sein, der Konkursrichter ist alle zwei Jahre zu
winnen kann leider
Gast und der Firma
100 geht es alles andere als gut. Dennoch erwartet der Vorstand
eine möglichst vorteilhafte Darstellung um von eventuellen eigenen Fehlern ab90
zulenken. Das folgende
Diagramm bildet die Umsätze als triste Realitäten unverschönt ab: kaum
Dynamik,
eher Stagnation, kein Grund zu viel Begeisterung.
80
110
70
100
60
90
50
80
40
70
30
60
20
50
10
40
0
1
30
2
3
4
5
6
7
8
9 10
Um Platz zu sparen und den Inhalt etwas zu komprimieren, wird ein Teil
der senkrechten Achse häufig abgeschnitten, so wie im nachfolgenden Diagramm.
10
Solange an einer unterbrochenen senkrechten Achse deutlich gemacht, dass etUm Platz
zu sparen
und den Inhalt etwas zu komprimieren, wird ein
0
was geschnitten wurde ist das noch vertretbar. Fehlt dieser Hinweis handelt es
Teil der senkrechten
Achse
so wie im nachfolgenden
1 2 3sich4um5Manipulation.
6häufig
7 8 abgeschnitten,
9 10
20
Diagramm. Solange
105 an einer unterbrochenen senkrechten Achse deutlich
Um Platz zu
sparen und den Inhalt etwas zu komprimieren, wird ein Teil
gemacht,
dass etwas
geschnitten
wurde ist so
das
vertretbar.Diagramm.
Fehlt dieser
der senkrechten
Achse
häufig abgeschnitten,
wienoch
im nachfolgenden
104
Hinweis
handelt
es
sich
um
Manipulation.
Solange an einer unterbrochenen senkrechten Achse deutlich gemacht, dass et103
was geschnitten wurde ist das noch vertretbar. Fehlt dieser Hinweis handelt es
102
sich um Manipulation.
105
101
104
100
1
103
2
3
4
5
6
7
8
9
102
101
100
1
2
3
4
5
6
7
8
9
10
Um die Manipulation noch effektiver einzusetzen wird im nächsten Schritt
die senkrechte Achse wieder gestreckt und der Umsatz wächst dynamischer.
136
10
Um die Manipulation noch effektiver einzusetzen wird im nächsten Schritt
die senkrechte Achse wieder gestreckt und der Umsatz wächst dynamischer. Bei
dieser Art der Darstellung wird kaum6noch
jemand auf die Idee kommen den
Kurvendiskussion
Erfolg der Firma anzuzweifeln.
Bei dieser Art der Darstellung wird kaum noch jemand auf die Idee kommen
den Erfolg der Firma anzuzweifeln.
105
104
103
102
101
100
1
2
3
4
5
6
7
8
9
10
Bereits deutlich manipuliert, aber die Möglichkeiten sind noch nicht erschöpft. Ein wenig stört noch der vergleichsweise flache Anstieg zwischen
Sieht
schon sehr der
gut Zwischenjahre,
aus, die Möglichkeiten
sind aber noch
den Jahren 6 und 10. Durch
Weglassen
was bedeutet
das nicht erschöpft.
Ein
wenig
stört
noch
der
vergleichsweise
flache
Anstieg
zwischen
eine Einheit auf der waagerechten Achse sowohl für ein Jahr als auch für drei den Jahren 6
und 10. Durch Weglassen der Zwischenjahre, was bedeutet das eine Einheit auf
Jahre steht, lässt sich der
derwaagerechten
Graph weiter
”optimieren”. Zusätzlich wird die
Achse sowohl für ein Jahr als auch für drei Jahre steht, lässt
Decke des Diagramms sich
etwas
gesenkt,
so
die Umsatzkurve
amdie
oberen
der Graph weiter dass
optimieren
“. Zusätzlich wird
Decke des Diagramms
”
rechten Rand geradezuetwas
das gesenkt,
Diagramm
durchbricht.
Um am
diesen
Effekt
noch
so dass
die Umsatzkurve
oberen
rechten
Rand geradezu das
Diagramm
durchbricht.
Um
diesen
Effekt
noch
zu
unterstreichen
zu unterstreichen bekommt der rechte Rand der Kurve noch einen dicken bekommt der
rechte
der an
Kurve
einenweggelassen.
dicken Pfeil. Ausserdem werden die Zahlen
Pfeil. Ausserdem werden
dieRand
Zahlen
dennoch
Achsen
an den Achsen weggelassen.
Im Alltag ist diese überzogene Art der graphischen Datenkosmetik
glücklicherweise nicht die Norm, sondern operiert vielmehr in der Mitte
zwischen dem letzten Schaubild und dem Ausgangsdiagramm [1] . Selbst
in der Werbung, in der Übertreibungen zum täglichen Geschäft gehören,
kommen solch extrem übertriebene Graphiken nicht allzuoft vor. Der
Schaden hält sich auch deswegen in Grenzen, da normalerweise in Annoncen
und Werbung nicht nach der Wahrheit gesucht wird. Umso unangenehmer
sind solch drastische Darstellungen in redaktionellen Texten, in denen man
sie eigentlich weniger erwartet wie z.B. Berichten über Börsenkurse und
Aktienverläufe.
137
13
Grundlagen
Im Alltag ist diese überzogene Art der graphischen Datenkosmetik glücklicherweise nicht die Norm, sondern operiert vielmehr in der Mitte zwischen dem
letzten Schaubild
Ausgangsdiagramm
[1] . Selbst
Neben den oben gesehenen
Formenund
derdem
graphischen
Datenkosmetik
gibtin der Werbung,
in der Übertreibungen zum täglichen Geschäft gehören, kommen solch extrem
es noch die Möglichkeit des Stauchens oder Dehnens der Achsen. Der Verübertriebene Graphiken nicht allzuoft vor. Der Schaden hält sich auch deswegen
lauf der Beschriftung in
istGrenzen,
mindestens
zweigeteilt.
Das heißt
da normalerweise
in Annoncen
undanstatt
Werbunglinear
nicht nach der Wahroder logarithmisch durchzulaufen,
ändert
die
Achsenbeschriftung
Funk-Darstellungen in
heit gesucht wird. Umso unangenehmer sind solch ihre
drastische
redaktionellen
Texten, in denen
man sie
eigentlich
erwartet wie z.B.
tionsvorschrift. Eine Gerade
mit konstantem
absolutem
Anstieg
proweniger
Periode
Berichten
über
Börsenkurse
und
Aktienverläufe.
flacht durch das Dehnen des zweiten Teils der waagerechten Achse im Wach-
stum scheinbar ab. Umgekehrt nimmt das Wachstum durch einen Dehnung
Neben den oben gesehenen Formen der graphischen Datenkosmetik gibt es
des ersten Teils der waagerechten
Achse des
scheinbar
zu.oder Dehnens der Achsen. Der Verlauf der
noch die Möglichkeit
Stauchens
Beschriftung ist mindestens zweigeteilt. Das heißt anstatt linear oder logarithmisch durchzulaufen, ändert die Achsenbeschriftung ihre Funktionsvorschrift.
7 Experimentmethodik
Eine Gerade mit konstantem absolutem Anstieg pro Periode flacht durch das
Dehnen des zweiten Teils der waagerechten Achse im Wachstum scheinbar ab.
Die Experimentmethodik
gibt nun
Gelegenheit
einigedurch
Punkte
ausDehnung
vorherigen
Umgekehrt
nimmt
das Wachstum
einen
des ersten Teils der
waagerechten
Achse scheinbar anzuwenden
zu.
Kapiteln auf die empirische
Softwaretechnik
bzw. weitere
allgemeine Kritik am Beispiel zu üben. Die Erläuterung der komplizierten
Umstände und Randbedingungen
unter denen die Experimente stattfinden
müssen, werden deutlich machen, dass selbst eine unbeabsichtigte MaDie Experimentmethodik gibt mir nun Gelegenheit einige Punkte aus vorherinipulation nur sehr schwer
zu vermeiden ist. Oberstes Ziel ist hierbei
gen Kapiteln auf die empirische Softwaretechnik anzuwenden bzw. weitere allgedie Aussagekraft der meine
Experimente,
die nurzu mit
Störvariablen
Kritik am Beispiel
üben.begrenzten
Die Erläuterung
der komplizierten Umstände
und unter sauberen Bedingungen
zustande
Nicht
immer müssen, werden
und Randbedingungen
unterkommen
denen die kann.
Experimente
stattfinden
machen, die
dass Rede
selbst eine
Manipulation
kann bei Manipulationdeutlich
von Vorsatz
sein,unbeabsichtigte
wenn man bedenkt
wie nur sehr schwer
zu
vermeiden
ist.
Oberstes
Ziel
ist
hierbei
die
Aussagekraft
der Experimente,
komplex Variablen voreinander abhängen oder wie schwer es ist Störfaktoren
138
auszuschliessen. Bereits erwartete Ergebnisse können ganz unbewusst
manipulierend wirken und der Vorwurf einer vorsätzlichen Manipulation
sollte daher gut geprüft sein.
Weite Teile zur Versuchsdurchführung und Methodik beziehen sich auf [2].
Sollte hier der Bezug zum Thema ”Kritik in Statistik” nicht erkennbar sein, so
sei darauf hinwiesen, dass auch Ergebnisse aus kontrollierten Experimenten
in der Softwaretechnik mit Hilfe von Statistik dargestellt werden. Die
Kritik der vorherigen Kapiteln kann leicht so verstanden werden, dass stets
Vorsatz und Bevorteilung der Grund für Manipulationen ist. Um dies zu
widerlegen oder zumindest ein paar Ansätze für mehr Verständnis anzuregen
werde ich kurz auf einige Probleme und Überlegungen erläutern, die bei der
Planung und Durchführung kontrollierter Experimente in Erscheinung treten.
Repräsentative Ergebnisse in Experimenten zu bekommen ist meist
nur unter strengen Bedingungen möglich, und auch dann bleiben häufig
berechtigte Zweifel an der Allgemeingültigkeit oder Aussagekraft, bedingt
durch die Umstände, unter denen die Ergebnisse zustande gekommen sind.
Zweifel können das gesamte Experiment in Frage stellen und sollten deswegen
soweit wie möglich durch sorgfältig geplante und durchgeführte Versuchsbedingungen ausgeschlossen werden. Denn auch ohne vorsätzliche Manipulation lässt sich eine Beeinflussung auf die Ergebnisse nur schwer ausschliessen
was sich im folgenden verdeutlichen wird. Als Basis sollte ein gelungener
Experimententwurf dienen, dessen Planung es einiger grundlegender Überlegungen bedarf, denn auch auf das wesentliche beschränkt bleiben immer
noch folgende Punkte:
• welche Gruppen
• in welcher Reihenfolge
• welche Aufgaben erledigen bzw. unter welchen Bedingungen arbeiten
und
• welche abhängigen Variablen dabei beobachtet werden sollen.
7.1
Randbedingungen
Die Fähigkeiten des Experimentators sind maßgeblich für das Ergebnis des
Experiments. Dabei ist taktisch kluges Verhalten und die Fähigkeit richtige
Entscheidungen in Detailaspekten zu treffen weitaus bedeutsamer als
theoretisches Wissen über Experimententwurf, Bedrohungen der Gültigkeit,
Statistik und ähnlichen Themen. Die Ursachen dafür liegen in den überaus
139
Grundlagen
schwierigen Randbedingungen unter denen softwaretechnische Experimente
stattfinden. Die Kosten und der Umfang des Experiments sind ein Aspekt.
Soll das Experiment mit hoch qualifizierten und ökonomisch sehr gefragten
Versuchspersonen durchgeführt werden oder kann ein gleichwertiges Ergebnis auch mit Studenten erreicht werden?
Muss auf hochqualifizierte
Versuchspersonen zurückgegriffen werden, wird die Mitwirkung schnell sehr
teuer, so dass als Ausgleich der Umfang der bearbeiteten Aufgaben nur
klein sein kann. Dem widerspricht, dass die zu untersuchenden Tätigkeiten
meist viel Zeit in Anspruch nehmen und eher langwierig und umfangreich
sind. Auch kann die Verfügbarkeit geeigneter Versuchspersonen ein Problem
darstellen. Die geforderten Kenntnisse sind häufig sehr spezifisch und eine
nachträgliche Vermittlung dieser Kenntnisse ist in vielen Fällen unrealistisch
oder nicht möglich. Je spezieller die Anforderungen desto schwieriger
gestaltet sich die Versorgung mit Versuchspersonen unter Beachtung der
Verwertbarkeit der Ergebnisse.
Die Auswahl der Aufgaben für die Versuchspersonen ist ebenfalls eine
sehr schwierige Aufgabe. Bedenkt man, dass die Aufgaben dem Experimentziel, der Qualifikation der Versuchspersonen und dem umsetzbaren
Arbeitsaufwand genügen müssen und auch von Seiten der Experimentatoren
nur ein realistischer Herstellungs- und Aufbereitungsaufwand gefordert werden kann, so wird dies nachvollziehbar. In vielen Fällen ist sogar unklar, wie
sich die Messung der relevanten Variablen überhaupt gestalten soll oder wo
die Möglichkeit zur gezielten Einflussnahme auf interessante, unabhängige
Variablen überhaupt besteht. Letzlich darf auch die Auswerbarkeit des
Experiments nicht aus den Augen gelassen werden.
Die vierte Randbedingung ist die technische Durchführung. Den Versuchspersonen eine Arbeitsumgebung zu bieten, die auf der einen Seite
geeignet, bestenfalls gewohnt erscheint, und auf der anderen Seite zugleich
eine korrekte Messung der unabhängigen Variablen zulässt, aber auch die
Kontrolle der unabhängigen Variablen erlaubt. Neben der Isolation von
äußeren Einflüssen zählt zu den problematischten Aspekten die technische
Infrastruktur in Form von Hard- und Sofware.
Als Folge der Randbedingungen liegt das Ziel von Experimenten in der
Softwaretechnik daher realistischerweise nicht in der Durchführung eines
perfekten Experiments, sondern vielmehr darin überhaupt ein brauchbares und zugleich relevantes Ergebnis zu erreichen.
Dr. Prechelt [2] hat eine Prioritätenliste für die Auswahl aus denkbaren
Entwurfsalternativen zusammengestellt, die Reihenfolge der wichtigsten
140
Eigenschaften billig, praktikabel, sicher und aussagekräftig ergibt folgende
Liste:
1. Die Kosten des Experiments, insbesondere Anzahl und Zeitaufwand der
Versuchspersonen, in einen realsitischen Bereich zu drücken.
2. Die Aufgaben so auszuwählen, dass das Experiment überhaupt praktikabel wird.
3. Die Chancen für ein Scheitern des Experiments zu minimieren. Dabei
insbesondere die Über- und Unterforderung der Versuchspersonen und
die Wahl der Aufgabe in Hinblick auf den aufzeigbaren Effekt der untersuchten Variable zu berücksichtigen.
4. Die Anzahl erhaltener Datenpunkte der abhängigen Variablen zu maximieren.
5. Minimierung zu erwartender Nebeneffekte, die eine Aussage des Experiments beeinträchtigen könnten
6. Maximierung der Zahl anderer eventuell relevanter Beobachtungen
(qualitative oder quantitative), um einen möglichen Nebennutzen des
Experiments zu steigern
Zusammenfassend lassen sich diese Überlegungen auf folgende Aussage
zuspitzen: ”Die Kunst erfolgreicher kontrollierter Experimente in der
Softwaretechnik besteht vor allem darin, einen geeigneten Aufbau zur
Untersuchung der gewünschten Fragestellung so weit herunter zu skalieren,
dass das Experiment praktikabel wird, ohne jedoch dabei die innere und
äußere Gültigkeit zu sehr zu beeinträchtigen oder den zu beoachtenden
Effekt zu verdecken.” ( [2] S.107) Oder kurz gesagt: ”Die Kunst besteht
darin, ein Experiment klein zu machen, ohne es kaputt zu machen.”
Eine methodische Vorgehensweise sollte bei Erfüllung aller Randbedingungen ein gültiges Ergebnis zu einer relevanten Fragestellung erzwingen und
gleichzeitig versuchen die Kosten zu minimieren.
7.2
Versuchspersonen
Der Einsatz von Versuchspersonen bringt weitere Variablen und Randbedingungen mit sich. Da wäre zum einen die Frage der Verfügbarkeit, als
auch der fachlichen Kompetenz der Versuchspersonen. Dabei stellt sich die
141
Grundlagen
nächste Frage nach Beeinträchtigung durch unterschiedliche fachliche Kompetenz. Existiert diese überhaupt und warum könnten dadurch Probleme
auftreten. Und inwiefern ändern sich Randbedingungen bei Experimenten
mit Teamarbeit im Gegenüberstellung zur Einzelarbeit. Wie sorgt man für
ausrechende Motivation?
7.2.1
Kompetenz
Die Frage nach der Kompetenz der Testpersonen ist gleichzeitig einer der
am häufigsten und schärfsten betonten Kritikpunkte. Die Tatsache das die
Versuchspersonen in den meisten Fällen Studenten sind ist Grund dafür,
dass manche Kritiker solche Experimente von vornerein verwerfen und behaupten die Ergebnisse wären nicht auf ”wirkliche” übertragbar. Mag das
auch manchmal der Wirklichkeit entsprechen, so ist diese Reaktion meist
überzogen. Dagegen spricht zum einen, dass der Unterschied zwischen (fortgeschrittenen) Studenten und Profis gar nicht so groß ist, und außerdem ist
er in vielen Fällen ohnehin kaum relevant. Das fortgeschrittene Studenten
”kurze” Zeit später selbst zu den Profis zählen wird ein Grund dafür sein,
hinzu kommt das die mittlere Berufserfahrung der Profis in vielen Bereichen
technologisch fortschrittlicher Softwareentwicklung recht kurz ist. Die Nachfrage war längere Zeit so groß, dass die Hochschulen ihr nicht gerecht wurden
und die Unternehmen zusätzlich viele fachfremde Akademiker wie z.B. Biologen und Chemiker eingestellt haben. Diese fachfremden Qualifikationen
erfordern normalerweise einige Jahre als Profi, um das von vornherein bessere
Qualifikationsniveau eines Informatikers auszugleichen. Zumindest bei einem
Teil der Profis wurde viel Zeit ihrer Berufserfahrung in die Schliessung einer
Lücke investiert, die fortgeschrittene (Informatik-) Studenten eigentlich nicht
mitbringen dürften.
Zahlreiche kontrollierte Experimente haben gezeigt, dass, von Anfängern
mal abgesehen, die Länge der Programmiererfahrung wenig Rückschlüsse
auf die Kompetenz eines Softwareingenieurs zulässt [2]. Die höhere fachliche Kompetenz bringt nicht selten eine sehr hohe Spezialisierung mit sich,
die bei Nichtübereinstimmung des Experiments eher kontraproduktiv ist. In
diesem Fall sind Studenten einem nicht zutreffend spezialisierten Profi sogar
vorzuziehen.
Je nach Experiment steht die Veränderung der Leistung bei Änderung der
unabhängigen Variable im Vordergrund und nicht die absolute Leitung. Von
daher stellt sich die Frage, ob Kompetenzunterschieden zwischen den Versuchspersonen überhaupt soviel Beachtung zukommen sollte. Die Relevanz von Kompetenzunterschieden hängt mit der resultierenden Arbeitsweise
142
zusammen. Bei grob gleicher Vorgehensweise, unabhängig von der Kompetenz der Versuchspersonen, ist auch die Relevanz weit geringer. Ermöglicht
eine höhere Kompetenz eine gänzlich andere Vorgehensweise beim Lösen der
Aufgabe, so darf damit gerechnet werden, dass sich auch die Unterschiede
zwischen den Experimentgruppen verändern können. Folgende Faktoren
begünstigen eine grundsätzlich andere Vorgehensweise einer weniger kompetenten Gruppe von Versuchspersonen im Vergleich zu einer kompetenten
Gruppe:
• Die Versuchpersonen sind generell noch ungeübt in der Lösung softwaretechnischer Aufgaben.
• Die Versuchspersonen sind in genau der untersuchten Tätigkeit zu
ungeübt.
• Die gestellte Aufgabe ist sehr kompliziert.
• Die gestellte Aufgabe ist sehr speziell.
• Die gestellte Aufgabe ist sehr umfangreich.
Verweise auf Literatur zu Beispielen für entsprechende Szenarios finden
sich in [2] Kapitel 8.1.
Aus obigen Überlegungen ergeben sich einige zusammengefasste Faustregeln
[2]:
• Experimente mit Anfängern sollte man vermeiden. Eine Verfälschung
der Ergebnisse durch möglicherweise völlig andersartige Arbeitsweise
könnte die Folge sein.
• von Punkt 1 abgesehen sind Experimente mit studentischen Versuchspersonen unproblematisch
• unabhängig von der Kompetenz der Versuchspersonen droht bei
Überforderung ein Scheitern des Experiments. Überforderung muss
sorgfältig vermieden werden.
- Die Überforderungsschwelle kann je nach Aufgabe bei Studenten
eventuell niedriger sein als bei Profis.
- Fehlendes Training der untersuchten Tätigkeit kann bei beiden
Gruppen eine Überforderung zur Folge haben.
143
Grundlagen
7.2.2
Homogenität
Grundsätzlich ist es wünschenswert, dass die Leistungsfähigkeit der Experimentteilnehmer möglichst homogen ist. Es kann sinnvoll sein unter Umständen auf manche Versuchspersonen von vornherein zu verzichten, wenn
deren Qualifikation zu stark von der der übrigen Teinehmer abweicht. Die
Ergebnisse eines kontrollierten Experiments werden um so klarer und aussagekräftiger, je eindeutiger (nicht unbedingt größer) die beobachteten Unterschiede zwischen den Versuchsgruppen ausfallen. Existieren jedoch große Unterschiede innerhalb der Versuchsgruppen, so erschwert es die Ausarbeitung
der Unterschiede zwischen den Gruppen, da diese verwischt werden. Leider lässt sich dieser Effekt kaum vermeiden, die indiduellen Unterschiede
zwischen Leuten aus der Softwarebranche sind erheblich. Die langsamere
Hälfte der Gruppe braucht typischerweise mindestens doppelt so lange wie
die schnellere - Unterschiede einzelner Personen fallen dementsprechend noch
größer aus (Abschnitt 16.3 aus [2] ). Der Unterschied der Mittelwerte von
Versuchs- und Vergleichsgruppe im Experimenteffekt ist mit allenfalls 70%
deutlich geringer.
Mit Hilfe von Vortests kann ein großer Teil der Unterschiede aus den Ergebnissen herausgerechnet und trotz starker Schwankungen scharfe Aussagen
erreicht werden. Dazu muss allerdings die zu erwartende relative Leistung
der Versuchspersonen vor dem eigentlichen Experiment bekannt sein.
7.2.3
Teams
Aufgaben in Experimenten können Gruppenarbeit erfordern, die nicht mit
einer seperaten Beobachtung und Auswertung von Teilnehmern in Einklang
zu bringen ist. Die gegenseitige Beeinflussung der Personen innerhalb eines
Teams machen ein gutes Experiment nochmals schwieriger; erhöhte Variabilität und fragwürdige Gültigkeit sind nur zwei der zusätzlichen Anforderungen. Auch der Aufwand für Bereitstellung und Verteilung der Aufgaben
dürfte abermals höher sein. Die Durchführung eines Experiments mit Teams
anstelle von Einzelpersonen bringt bei gleicher Personenzahl und gleichem
Zeitaufwand eine geringere Anzahl von Datenpunkten. Das ist ein deutlicher
Nachteil, da die gewonnene Schärfe der Aussagen abnimmt. Ein zumindest theoretischer Vorteil ist das Ausmitteln individueller Unterschiede der
einzelnen Versuchspersonen innerhalb eines Teams. Dem steht ein weiterer
möglicher Nachteil gegenüber, dass ein Team aufgrund von Kommunikationsschwierigkeiten oder besonderer Gruppendynamik wesentlich schlechter oder
aufgrund von Synergieeffekten spürbar besser ist als das Mittel seiner Mitglieder einzeln betrachtet. Experimente mit Teams bieten ein, bei mindestens
144
8 Zusammenfassung
gleichen Kosten, höheres Risiko eines unbrauchbaren Ergebnisses. Weitere
Unsicherheiten bringt die Zusammenstellung der Teams, die wiederum eine
Beeinträchtigung der Leistung und schwer kalkulierbare, gruppenabhängige
Lerneffekte mit sich bringt.
7.2.4
Motivation
Im letzten Abschnitt zum Thema Versuchspersonen möchte ich noch ein paar
Worte zu Motivation und Teilnahmeanreizen loswerden. Motivationsunterschiede zwischen den Gruppen oder einzelnen Teilnehmern sind natürlich
Gift für jedes Experiment und zerstören die innere Gültigkeit. Auch eine
gruppenübergreifende extrem hohe oder niedrige Motivation bedroht das Experiment, denn sie kann Ergebnisse an den Rand der Bedeutungslosigkeit
führen. Eine extrem hohe Motivation wird ohne gezielte Mitwirkung der
Experimantatoren wohl kaum auftreten und kann gegebenenfalls von ihnen
ohne Schwierigkeiten gedämpft werden. Eine extrem niedrige Motivation
kann Folge einer unfreiwilligen Teilnahme am Experiment sein, der man mit
Teilnahmeanreizen entgegentreten kann. Finanzielle Anreize können je nach
Höhe und Vergabebedingungen entweder zu einer unnatürlich hohen Motivation oder eine Abzocker-Mentalität fördern (niedrige Motivation).
8
Zusammenfassung
Im Bezug auf die Softwaretechnik ist zumindest deutlich geworden wie schnell
man sich unabsichtlich eine vorsortierte Stichprobe eingefangen hat, einfach weil es sehr schwierig ist für alle Teilnehmer gleiche Bedingungen bereitzustellen bzw. überhaupt gleichwertige Teilnehmer(-gruppen) zu bekommen. Auch der Schluss einer falschen Kausalität von Korrelationen kann,
wegen schlecht zu erkennenden Abhängigkeiten, leicht unterlaufen. Die abhängigen Variablen sind dabei viel schwieriger zu erfassen und messen als
bei anderen statistischen Erhebungen, die beispielsweise von vornherein auf
metrischen Einheiten oder Skalen aufbauen.
Einige Themen die weiteren Anlass zur Kritik bieten wie beispielsweise der
synthetische Superlativ sind nochmal ein Stückchen weiter vom eigentlichen
Thema ”Methoden der empirischen Softwaretechnik” entfernt und bedürften
einiger Erklärung im Zusammenhang mit Statistik. Dennoch ist hoffentlich
ein Bogen von allgemeiner Kritik in Statistik zu speziellen Problemen in
der Experimentmethodik der Softwaretechnik erkennbar. Die Demonstration
und Aufdeckung von Manipulation an Fakten gibt dem Leser im besten Fall
etwas mehr Vorsicht im Umgang mit Zahlen und Diagrammen auf den Weg.
Wissen, das man auch alltäglich und nicht nur ”am Computer” verwenden
145
Grundlagen
kann. Aber auch von aktiver Seite bei der Ermittlung und Darstellung ermittelter Ergebnisse die Sachlichkeit nicht zu vernachlässigen und für möglichst
”saubere” Versuchsbedingungen - schon im eigenen Interesse - zu sorgen. Die
Inhalte der Abschnitte jenseits der Softwaretechnik lassen sich weitestgehend
auch auf die Experimentmethodik, statistische Zahlen und Ergebnisse im
Reiche des Computers übertragen. Insbesondere Veröffentlichungen aus dem
Bereich der empirischen Informatik bringen häufig Statistiken und Experimentergebnisse mit sich. Eine Aufdeckung solcher Manipulationen - bestenfalls mit Hilfe der vorangegangenen Beispiele - bleibt nun Sache des Lesers
und hoffentlich - aufgrund verantwortungsvoller, wissenschaftlicher Arbeit reine Utopie.
References
[1] Walter Krämer, So lügt man mit Statistik, Piper 2003 3. Auflage
[2] Lutz Prechelt, Kontrollierte Experimente in der Softwaretechnik,
Springer 2001
[3] Die Zeit, Cornelia Stolze, Die fremde Welt der Zahlen, 33-2002
[4] Gerd Gigerenzer, Einmaleins der Skepsis, Berlin Verlag 2002
146
The 28:1 Grant/Sackman legend
René Püttmann
Keywords: Grant, Sackman, Prechelt, work time, interpersonal variation, debug
time, programmer-performance,
Abstract
In the year 1967 Grant and Sackman published a paper on the
topic of interpersonal variation. Their experiments led them to the
conclusion that the interpersonal variation in a group of programmers
solving the same task is 28:1, this means that the slowest programmer
takes 28 times longer than the fastest programmer.
This report takes a look at Lutz Prechelt’s paper ”The 28:1
Grant/Sackman legend is misleading, or: How large is interpersonal
variation really?”, which contradicts the results of Grant and Sackman. For the big picture we also take a look at related works of Grant
and Sackman.
1
The paper(s) of Grant and Sackman
In 1967 E. Eugene Grant and Harold Sackman published ”Exploratory Experimental Studies Comparing Online and Offline Programming Performance”
a milestone in programmer-performance comparison. This paper provides
the basis for a ratio of 28:1 being the worst case interpersonal performance
difference.
Early in the year 1967 Grant and Sackman had published another paper on the same topic, called ”An Exploratory Investigation of Programmer
Performance Under On-Line and Off-Line Conditions”, which is actually a
relatively unknown, long-version of the other paper.
1.1
The experiment of Grant and Sackman
With their experiment, which was conducted one year before the release of the
two papers, Grant and Sackman intended to compare the program debugging
performance under two conditions, one being online programming, the other
offline programming.
In offline programming, also called closed shop access, programs are run,
one at a time, in a so called closed shop, a rather large computer installation,
where the programs are run by shop personnel. The programmer is usually
not present at the time the programs are run. The typical turnaround time,
the time between submission of the program and return to the programmer,
for these installations was 24 to 48 hours.
Online programming, also called direct access, is comparable to nowadays
programming habits, e.g. the programmer debugs a program using an interactive environment on a workstation. The advantages of online programming
towards offline programming should be obvious.
Twelve subjects participated in the experiment of Grant and Sackman.
Their qualification varied to some degree as can be observed in figure 2,
though all were professional programmers.
The programmers were split into two groups of 6 subjects each. Both
groups were assigned two tasks, each group had to solve one task by online
programming and the other one by offline programming, as shown in figure
1.
The two tasks or program problem statements were especially designed
for the experiment. One task was to write a program to solve algebraic
equations with a single dependent variable, the solutions were called Algebra
programs.
The other program should calculate the only path through a 20 by 20 cell
maze. These programs were referred to as Maze programs.
150
1 The paper(s) of Grant and Sackman
Figure 1: ”latin square experiment [2]” setup
The debugging time started as soon as the compiler didn’t detect any
serious format errors within the program coded by the subject. It ended
when the program was able to process a standard set of test inputs, without
generating errors. Not only the programmer Man Hours but also the CPU
time were collected for comparison of online and offline debugging.
Man Hours are the actual hours spent debugging, including the
turnaround time in the offline cases. The offline cases were simulated by
letting the subjects take a two hour break between start and end of each debugging step. The experimental staff took care of a most exact hour recording, discrepancies between the time observed by the experimental staff and
the reported time were resolved by interviewing.
1.2
Their interpretation of the data
In their earlier paper Grant and Sackman clearly state that the characteristics of the acquired data ”pose three serious problems for statistical analysis”.
All these problems relate to the treatment of the data with statistical methods. Grant and Sackman interpret the data of the rows labeled ”Criterion
Measures for Debugging Performance” as follows, the Debug Man Hours are
always smaller in the online cases, for the Algebra problem it’s a 50% gain
and for the Maze problem it took the subjects only a third of the time, that
they needed in the offline case. When comparing the CPU time these ratios are turned around, the online cases took approx. 30% more CPU time
than the offline cases. But as Grant and Sackman point out the statistical
significances of these ratios is of lesser importance.
According to Grant and Sackman, one can say, when taking the other
datasets into account, that the two groups ”were more or less evenly matched
on programming skill for the two experimental problems”, when taking program size and program running time into account.
Grant and Sackman concluded that the data can be used for statistiMethoden der empirischen Softwaretechnik
151
Figure 2: experimental data matrix [2]
152
cal methods, though there are some restrictions. The Latin-Square design
used for this experiment, requires to analyse the variance. This analysis requires three basic conditions: normal distributions, homogeneous variances
and linear relationships in the effects of the experiment. Due to the positively skewed distributions of the four ”Criterion Measures for Debugging
Performance” the first condition can not be satisfied. Due to the large differences between the standard deviations for Algebra and Maze performance the
second condition also poses a problem. Only the third condition is satisfied
without any limitations.
To get a more homogeneous variance and therewith satisfy the second
condition, a square-root transformation was applied upon the data, according
to Grant and Sackman a common course of action, when dealing with extreme
data dispersions.
Figure 3: Comparative results of three analysis of variance [2]
Grant and Sackman applied three types of analysis of variance (see figure
3) to the Latin-Square experimental design (see figure 1) for the two criterion
measures Debug Man-Hours and CPU Time. The entries in figure 3 show
the level of statistical significance for each of the six analysis of variance for
CPU Time as well as Debug Man-Hours. A detailed look at variance analysis
can be found in the section Mathematical fundamentals.
Now that the data is prepared for analysis, Grant and Sackman took a
closer look at the Average Debug Man-Hours (see figure 1). One can observe, that the Offline Debug Man-Hours increase with growing turnaround
time, while the Online Debug Man-Hours are constant. This is what one
would have assumed, as the turnaround time is only related to the Offline
Experiment.
Grant and Sackman used different statistical methods to get a global
view of the significance of the data. Some of these will be explained in the
chapter Mathematical fundamentals. The final chapter of Grant and SackMethoden der empirischen Softwaretechnik
153
Figure 4: Debug Man-Hours estimated as a function of turnaround time
from the experimental data [2]
man’s paper, called Interpretation, focuses on three major objectives: online
vs. offline programming performance,the analysis of individual differences in
programming proficiency and the implications of the methodology and findings
for future research. We will have a closer look at the first objective.
The online programming resulted in a significantly better performance
than the offline programming, when regarding the needed Debug Man-Hours.
But Grant and Sackman also point out that due to ”the exploratory nature
of this study” and the need of further research every result has to be second
guessed. The experiment only simulated the offline environment via an online environment therewith it may be possible that, had it been vice versa,
the result would have been different. Furthermore ”the use of new or different programming languages” might cause the results to differ. They also
point out another problem, there is no widely accepted classification scheme
for programmers, therewith the comparison of the datasets turns out to be
rather difficult. They also point out that the difference between offline and
online programming decreases with decreasing turnaround time, leading to
a tie when setting turnaround time to zero. This leads to the assumption
that the timespan of the turnaround time cannot be efficiently used by the
programmer, but they also make clear that further research is necessary in
order to affirm this assumption. Another problematic element, according
154
to Grant and Sackman, was the choice of the tasks the programmers had to
solve. They thought the Maze and Algebra to be quite different as they afford
different skills. In the experimental data matrix one can observe that there
is no correlation between the programmer’s experience and the results of the
programming performance measurements. Grant and Sackman assume that
with greater experience the programmers also get more specialized, therewith their advantage in solving the two rather easy tasks is very slim. The
offline condition resulted in approximately 30% less CPU time usage, Grant
and Sackman name two reasons for this. On the one hand one may assume
that the online programmers are willing to use a trial-and-error approach
in solving the tasks, therewith reducing their own time and effort in solving
the problem by the cost of more CPU time usage. On the other hand the
simulation of the offline environment had it’s limits, normally the programmer gets the complete dumps of core memory, but in the experiment only
limited dumps of selected areas of core memory could be gathered, therewith
reducing CPU time significantly.
155
2
Overview of this report
This report will give a detailed analysis of the paper The 28:1 Grant/Sackman
legend is misleading, or: How large is interpersonal variation really? by
Lutz Prechelt. Therefor the original paper An Exploratory Investigation of
Programmer Performance Under On-Line and Off-line Conditions by Grant
and Sackman was presented in the first section.
Section 3 focuses on the mathematical fundamentals that were, in part,
already mentioned in section 1. All of the statistical methods presented in
[1] will be discussed.
The paper of Lutz Prechelt will be looked at in section 4. We will also
give a more diverse look on the topic of interpersonal variation by drawing
connections to the original Grant/Sackman paper.
The last section points out several statistical tests and summarizes the
main topics.
2.1
Motivation
For more than 30 years the Grant/Sackman theory, derived from their paper
[2] published in 1966/7, was unquestioned. Lutz Prechelt’s paper [1] combined the results of a vast number of experiments to negate the 28:1 theory.
In this report we will give a critical view of Lutz Prechelt’s line of argument.
But more important, it will be shown that the 28:1 theory does not hold true.
3
Interpretation of experimental datasets
In this section a wide, but still detailed, view upon the mathematical fundamentals needed for the interpretation of experimental data or experimental
datasets will be given. Furthermore the difficulties of data interpretation
based on one experiment and also on a whole set of different experiments
will be outlined.
3.1
Interpretation of interpersonal work time differences
When attempting to interpret interpersonal work time differences one has
to keep some general points in mind, which could have affected the results
of the experiments. Five question show the main difficulties that come with
comparing results of different experiments:
• Were time limits enforced in any of the experiments?
156
3 Interpretation of experimental datasets
• Did the subjects interact during the experiment? (e.g. if several subjects worked in one room social pressure could have influenced the work
time differences)
• Did special circumstances in a particular experiment lead to very long
or very short work times, which cannot be taken into consideration
when comparing the whole set of experiments? (Obviously this would
have to be addressed in the interpretation of the data)
• Was work time an importance performance variable in the experiment?
(If not the data could might not be very reliable)
• Is there any information about the resolution and accuracy of the time
measurement? Did the subjects record the work time themselves ?
One can easily imagine that the interpretation of the work time differences
of a set of experiments can turn out to be rather difficult. This leads us right
back to the topic of the paper: Is 28:1 a legend?
One of the major problems with the interpretation of data of a set of
experiments is the inhomogeneity of the data. One way to get a more comparable dataset is comparing maximum/minimum ratios.
Comparing maximum/minimum ratios is a very easy method to reduce
the impact of outliers. This, of course, can be done in different ways, the
most common approaches are worst versus best quarter and worst versus best
half. In the experiment of Grant and Sackman the worst quarter would be
the slowest quarter and the best quarter would be the fastest quarter.
Of course comparing the best and worst quarter, or the best and worst
half in that aspect, the interpersonal work time difference - ratio is reduced.
In the paper of Grant and Sackman the worst quarter to best quarter ratio
for the algebra debug hours is 5.9 to 1 and the worst half to best half ratio
3.8 to 1, bear in mind that the original worst subject to best subject ratio
was 28 to 1. The maze debug hours result in a worst to best quarter ratio of
7.5 to 1 and a worst to best half ratio of 5.125 to 1, while the worst to best
subject ratio was 26 to 1.
By now it should be obvious, that it is relatively easy to willingly or
unwillingly interpret experimental results in such a way that they do not
lead to a correct conclusion.
157
4
The paper of Lutz Prechelt
In Lutz Prechelt’s paper we get a different view upon the experiments of
Grant and Sackman. In his paper he shows that the propagated 28 to 1 ratio
is not applicable when considering work time differences.
4.1
28:1 is it a legend?
According to Lutz Prechelt 28:1 is a legend, he gives three reasons ”it is
wrong”, ”comparing the best with the worst is inappropriate” and ”one should
use more data [than just 12 subjects] to make such a claim”. In this aspect
two very important points should be considered, Grant and Sackman’s ratio
of 28 to 1 yields from ”the union of the groups debug Maze online and debug
Maze offline”, which obviously is problematic due to the different approaches
of the two groups to solve the problem. Furthermore three of the 12 subjects
of the experiment programmed in an assembly language, therewith taking
longer time to solve the tasks. The working time of two of those subjects
was the longest of all 12 participants. When we just take these two points
into consideration and look at the remaining 9 participants and at separate
groups, the ratio drops to 9.5 to 1.
This leads us to the question ”how should work time differences or variability be measured?” One option is to compare the medians of the partitions.
First we should have a look at the notation chosen by Lutz Prechelt. SFx
= q100−x/2 /qx/2 with qx being the x% quantile of the distribution. Now we
have to define quantile qx , given a set of n sorted numbers qx is the value of
the number at position round(x ∗ (n + 1)), if n is odd and the value of the
number at position (round(x ∗ (n + 1))+round(x ∗ (n)))/2 if n is even.
When applying the quantile method to the experiment data of the
Grant/Sackman experiment we get the following results (see figure 5).
When we compare these to table 1 of [1], we realize that the numbers do
not compute. One explanation could be that, due to the bad quality of the
original paper [2], different values were taken from figure 3 [2].
In figure 6 different quantiles (10%/90%; 25%/75%; 50%) along with their
range are presented. A good indication for the quality of the measurements is
the distance between the fat dot (50%) and the M, if they are close together
the experimental data can be suspected to be of a higher quality than when
they are far apart, but notice that this is only a indication.
One may notice that in most cases none(lines 1, 2, 5) or only one(lines 3,
4, 6, 7, 8) individual took much longer than the rest. We can conclude that
the high values of SF0 result from these individuals. By now it should be
obvious that comparing the worst with the best individual is not sufficient
158
4 The paper of Lutz Prechelt
Value
Coding Algebra
Coding Maze
Debugging Algebra
Debugging Maze
From [2]
15.8
25
28,33
26
SF0 of all values
15.8
25
28,33
26
SF25 of all values
8
11.5
6.5
10.25
SF50 of all values
4.73
6
2.5
4.1
SF0 offline
12.57
12.5
8.5
5.77
SF25 offline
7.79
8.11
4.67
4.04
SF50 offline
5
4.6
1.34
2.92
SF0 online
10.09
12.5
14.16
12.5
SF25 online
5.34
8
7.47
5.33
SF50 online
3.16
8
4.38
1.75
Figure 5: Measures of variability
159
Figure 6: Work times of the individual subjects in the groups of the
Grant/Sackman experiment in minutes. The box plot indicates the
quantiles at 10%/90% (whiskers), 25%/75% (box) and 50% (fat dot), the
mean (M) and the standard error of the mean (dashed line) [1]
160
to get a clear picture and therewith we may already put the 28:1 ratio into
doubt.
4.2
Size of interpersonal work time difference
For further analysis, Lutz Prechelt compared the data of 61 different experiments. Those experiments were partly taken from reports, as well as directly
conducted by the research group of Lutz Prechelt. When comparing the data
we have to keep in mind that the experiments were conducted by different
researchers therewith the data might be influenced by things like: social pressure, time limits, work time might not have been the main point of interest,
resolution of the time measurement might be unknown, though in most cases
it was either one or five minutes.
Now the method introduced in the previous subsection is used to evaluate
the data. Though the tables taken from [1] include also other aspects, we
will focus our attention on the debug and program/coding data.
Figure 7: Only groups of 5 or more subjects were taken into account. The
groups are distributed among the tasks as follows: understand(28 groups),
test/debug(10 groups), review(22 groups, most being rather small),
program(23 groups), maintain(54 groups)[1]
Even in a worst-case-scenario we would have 50 individuals in the
”test/debug”-section and 115 individuals in the ”program”-section, therewith
the base of individuals of the analysis is four to 10 times as large as in the
Grant and Sackman experiment. From the figure 7 we can actually take
161
concrete numbers, the mean of the ”test/debug”-section is around 11 to 12,
therewith we got approximately 110 to 120 individuals in this section, the
program section is even bigger with approximately 200 individuals. This
puts us to a 10:1 ratio for the ”test/debug”-section and a 17:1 ratio for the
”program”-section compared to the Grant/Sackman experiment.
Figure 8 shows that besides the Grant/Sackman experiment also other
experiments yield results with a ratio similar to the famous 28 to 1. But
in general the ratios are much smaller, even with this most times unsuitable
evaluation method. We can see that the SF5 0 of the SF0 evaluations gives
a range of approx. 3 to 12 for test/debug and a range of approx. 4 to 20 for
program/coding.
Figure 8: Each point represents SF0 (slowest/fastest individual quotient)
of a group. The scale is logarithmic. [1]
When we take the SF2 5 of the groups into account we notice that the
margin of the results is rather narrow, especially when leaving aside the most
extreme outliers. The range of the test/debug experiments, when evaluating
the results with the SF5 0-method, are within the range of 2 to 4.5 and the
program/coding experiments are within a range of 2.25 to 6.5.
Of course the differences are reduced even more when we compare the
SF5 0 of the different groups, this can be seen in figure 10 [1]. We can see
that the difference between the slowest and the fastest half of each group of
the ”test/debug”-case is around 2, while the difference for the ”program”-case
is in a range of 2 to 5.
162
Figure 9: Each point represents SF2 5(slowest/fastest quarter quotient) of
a group. Only groups with 9 or more individuals were taken into account.
One point of test/debug is at 11.4 and two points of program/coding are at
10.9 and 12.[1]
Figure 10: The points represent the SF5 0(the quotients of the medians of
the slower and the faster half) of the different groups. [1]
163
Now after evaluating more than 600 subjects from more than 100 experimental groups Lutz Prechelt presents us the results shown above. At
this point we should take another look at the data from the Grant/Sackman
experiment and especially at figure 2. One might be surprised that the differences are extremely small considering that we have the data of 12 subjects
on the one hand and the data of approx. 200(110-120 in the ”test/debug”groups) on the other, when considering the individuals of the ”program”groups. While we got a range of roughly 1.2 to 3.7 for the SF5 0 of the
”test/debug”-groups in the Prechelt experiment we got a SF5 0 of the Grant
and Sackman experiment that ranges from 2.5 to 4.1 and the same ranges
for the ”program/coding”-groups are approx. 1.7 to 7.3 for the Prechelt experiment and 4.73 to 6 for the Grant and Sackman experiment. Even if we
consider the SF5 0 of the Prechelt data the ranges don’t change significantly,
1.7 to 2.6 in the ”test/debug”-groups and 1.8 to 5 in the ”program/coding”groups.
We may conclude that the 28 to 1 ratio is misleading and not useful when
considering work time distributions, still the Grant and Sackman experiment
does yield similar results when applying the same statistical operations. The
work time difference for debugging can be assumed around 1.7 to 3 while the
work time difference for programming can be assumed to be around 1.8 to 5.
4.3
Shape of work time distribution
When talking about interpersonal variation we also have to consider distributions and especially how we can characterize the interpersonal variation
sufficiently by distribution functions.
First we should take a look at the standard deviation function. When
given a set x1 , ..., xn of values. We define the arithmetic mean(M ) of this
set as:P
x̄ = n1 ni=1 xi , and we define the standard deviation as
q P
σ = n1 ni=1 (xi − x̄)2
In figure 11 we see the comparison of the actual value of SF2 5 with the
normal distribution of SF2 5. It is obvious that the actual values are nearly
always below the normal distribution values. One may conclude that the
normal distribution function does not characterize the interpersonal work
time variation sufficiently.
When examining actual distributions of large enough groups, one will
notice that using a density estimator function, Prechelt uses Gaussian kernels, can provide useful results. The Gaussian kernel used is 2(max(X) −
min(X))/log2 (|X|) for a work time value X, while max(X) and min(X) are
164
Figure 11: Comparison of the actual and a theoretical value of SF2 5.
Note that the axis are logarithmic. [1]
the boundaries set by the standard deviation. Despite the seemingly good
results one may not draw any conclusions from the modified data , because
- according to Prechelt - ”samples of the given size sometimes look quite
weird”, this is even the case with some ”normal distribution”-samples.
Still one may conclude that positive skewness is a typical work time data
phenomena. This is quite logical as an individual might take endlessly long
to perform a task but not endlessly short.
To get a rather accurate estimate of the actual shape of work time distribution, Prechelt uses another approach by leveling the different sets of data.
This is done by dividing the values of the data sets by the average value of
the experiment group, resulting in a mean of one for each group.(see figure
12)
Besides the skewness, which, according to Prechelt, tends to range from
1 to 2, one might also notice that the work time variability of ”test/debug”
and ”programming”, though larger than those of the other shown tasks, are
still relatively small, with a means SF5 0 of 2.4 for ”test/debug” and ”programming”.
165
Figure 12: Virtual groups created by leveling the mean of each group to 1.
[1]
4.4
Effect sizes
After this rather theoretical approach we should turn our attention to the
practical use of work time data analysis. Besides the rather obvious goal
of contradicting or proving the 28 to 1 ratio, we also would like to find out
something about ”How to compare two sets of data”, so that we can decide
whether one approach of solving a task is better than another, when taking
things like costs into consideration.
First we define effect size, Prechelt presents us two different definitions
E1 and E2 . Given two sets of data A and B and assuming hat on average A
is faster than B, we can use the following formulas:
mean(A)
−1
E1 = mean(B)
E2 =
mean(B)−mean(A)
σ(mean(A∪B))
Now we should have a look at the effect size of the different tasks (see
figure 13). Notice that the effect sizes exceed 0.5 and a high degree even
exceeds 1.0 for both test/debug and program/coding.
Obviously the question is ”How come the effect sizes are so large?”, this
can be explained by the high impact small groups have on this analysis, if we
subtract the standard error of the effect size we get a SF5 0 in the boundaries
of 0 to 0.5 which is much closer to the prediction made by Prechelt.
166
5 Summary
Figure 13: Effect size of the work time of different tasks. [1]
5
Summary
We gave a detailed look into the paper of Grant and Sackman [2] as well as
a look upon the paper of Lutz Prechelt [1] along with his criticism of the
Grant and Sackman paper [2]. Along the way different statistical methods
were presented and explained.
5.1
Conclusion
Surely the 28 to 1 ratio does not hold stand against a critical analysis. And I
would also agree that the 2 to 1 ratio presented by Prechelt is a much better
ratio to use for individual work time differences.
But when discussing [2] one still must take into account two most important points, never in the whole paper do Grant and Sackman argue that the
28 to 1 ratio is a legit ratio to use for the analysis of work time differences
and they also explicitly point out that their data and also their conclusions
should be used with care and need further reviewing. By using the appropriate methods we could show that similar numbers could be taken from the
12-individuals-experiment of [2], as were concluded by Prechelt from the 600individuals-data-set of [1], namely a ratio of roughly 2 to 1 for the individual
work time difference for the task test/debug.
One should also bear in mind, that 2 to 1 still is a ratio conducted by
167
relatively simple statistical methods, more complex methods might lead to
a different ratio. A perfect method surely doesn’t exist; one can find good
reasons for the use of quantiles, still one might find as good reasons to use a
different method.
6
Literatur
1. Lutz Prechelt - The 28:1 Grant/Sackman legend is misleading, or: How
large is interpersonal variation really ?
2. Grant and Sackman - An Exploratory Investigation of Programmer
Performance Under On-Line and Off-Line Conditions
3. Grant and Sackman - Exploratory Experimental Studies Comparing
Online and Offline Programming Performance
4. Harold Sackman and J.B. Munson - Investigation of Computer Operating Time and System Capacity for Man-Machine Digital Systems
5. Harold Sackman - Managing the Economics of Computer Programming
6. Lutz Prechelt - An empirical study of working speed differences between
software engineers for various kinds of task
168
Die Annahme der statistischen
Unabhängigkeit bei
Multiversionsprogrammierung
Christian Mattar
Keywords: N-version Programming, Dependability, Reliability
Abstract
In diesem Paper wird zunächst eine Übersicht über Multiversionsprogrammierung und den zugehörigen Prozessen dargestellt.
Die einzelnen Untereinheiten “N-Version Programming Process”, “NVersion Software” und “N-Version Executive” , aus denen die Multiverionsprogrammierung aufgebaut ist, werden betrachtet. Weiterhin
wird ein Experiment von Knight & Leveson dargestellt, in dem die hintergründigen statistischen Annahmen in Frage gestellt wurden. Dabei
wurden 27 Programme nach derselben Spezifikation erstellt, und jeweils einer Millionen Testfälle ausgesetzt. Ausfälle der Programme wurden dann auf Korrelation geprüft und eine Wahrscheinlichkeitsanalyse
durchgeführt. Auf einige Fehler wurde dabei genauer eingegangen.
Das Experiment verursachte teils sehr negative Kritiken, die Autoren
widerlegten diese jedoch in einer weiteren Veröffentlichung. Als Endergebnis wurde festgehalten, dass Multiversionsprogrammierung die
Verlässlichkeit nicht so stark verbessert, wie vorher angenommen.
1
Einleitung
Die Verlässlichkeit von Software wird in der zunehmenden Automatisierung
ein immer wichtigerer Faktor.
Seit vielen Jahren schon besteht der
Trend, Systeme, die früher komplett manuell gesteuert wurden, nun zur
Verbesserung der Effizienz zumindest teilweise durch Computer steuern zu
lassen. Gleichzeitig jedoch nimmt die Komplexität dieser System zu, so
dass es nahezu unmöglich ist, Fehlerfreiheit zu garantieren. Formale Beweistechniken existieren zwar, sind aber ein dermaßen aufwändiger Prozess,
das diese nur für kleine Projekte praktikabel sind. Um dieses Problem dennoch in den Griff zu bekommen, hat man sich schon in den 70er Jahren
mit dem Ansatz von “Multiversionsprogrammierung” oder auch “N-version
programming” beschäftigt. Ähnlich wie auch bei Hardware, bei der Teile
mehrfach redundant ausgelegt werden können, um ein Versagen des Systems bei Fehlverhalten nur eines Teils zu verhindern, soll auch die Software
mehrfach implementiert sein, damit im Fehlerfall einer einzelnen Variante
dennoch ein fehlerfreier Output einer der übrigen Varianten erfolgt.
Jedoch unterscheiden sich derartige Softwarefehler von der Art her stark von
Hardwarefehlern: Da sogar komplexere Hardwaresysteme noch formal verifizierbar sind, treten dort Fehler i.d.R. nur durch Verschleiss oder fehlerhafte
Wartung auf. Es können also identische Systeme mehrfach eingesetzt werden, da es unwahrscheinlich ist, dass alle gleichzeitig ausfallen. Bei Software
hingegen treten Fehler durch mehrdeutige Spezifizierung oder fehlerhafte Implementierung auf – beides Probleme, die sich durch mehrfaches Einsetzen
identischer Software nicht lösen lassen.
Ein Beispiel für eine derartige sinnlose Redundanz ist der misslungene
Start der Ariane-5 Rakete im Juli 1996: Ein Teil der Flug-Kontrollen der
Rakete war vom Vorgänger Ariane-4 übernommen worden. Einige der FlugParameter waren in der neuen Variante jedoch größer als in der alten, so
dass ein Überlauf zu Stande kam. Dieser Fehler wurde ordnungsgemäß vom
Computer entdeckt, was dessen Abschalten zur Folge hatte. Ein redundanter Computer existierte zwar, aber sowohl Hardware als auch Software waren
komplett identisch, so dass dieser auf denselben Fehler traf und sich ebenfalls
abschaltete. Die Flug-Kontrolle konnte somit nicht aufrechterhalten werden
und die Rakete brach bei 4000 Meter Höhe auseinander, was die Selbstzerstörung einleitete.
Software-Redundanz macht also nur Sinn, wenn in den tatsächlichen Defektquellen von Software – den Implementierungen und den dahinführenden
Denkansätzen – Redundanz vorliegt. Für n-fache Redundanz werden also
wahrscheinlich n verschiedene Entwicklungs-Teams benötigt, die unabhängig
voneinander arbeiten. Doch selbst dann ist fragwürdig, ob die erheblichen
170
2 Methodik der Multiversionsprogrammierung
Mehrkosten, die durch ein solches Verfahren entstehen, gerechtfertigt sind.
Schließlich ist davon auszugehen, dass die meisten Fehler gerade in den algorithmisch schwierigsten Teilen des Programms auftreten, und sich deshalb
trotz Implementationsunterschiede gerade an bestimmten Stellen häufen.
Neben einer eingehenderen Beschreibung der Multiversions-Programmierung
soll deswegen auch ein Versuch dargestellt werden, in dem empirisch der
Nutzen dieses Ansatzes getestet wurde. Es soll bereits an dieser Stelle vorweggenommen werden, dass die Effektivität dieser Entwicklungsart durchaus
umstritten ist.
2
Methodik der Multiversionsprogrammierung
Konkret beschreibt Multiversionsprogrammierung einen Prozess, bei dem
aus einer einzigen Spezifikation von mehreren unabhängigen Entwicklerteams
jeweils eine eigene Implentierung produziert wird. Dabei ist insbesondere darauf zu achten, dass die Unabhängigkeit auch tatsächlich gegeben ist: Professioneller Kontakt zwischen den Teams sollte auf jeden Fall vermieden werden.
Für die Spezifikation sollte am besten eine formelle Spezifikationssprache benutzt werden. Dies hat den Vorteil, dass einerseits Mehrdeutigkeiten und
Ungenauigkeiten vermieden werden, andererseits aber keinerlei Implementationsdetails vorgegeben werden, da das Verwenden möglichst verschiedener
Programmiersprachen, Compiler und Algorithmen für jede einzelne Version
des Programms erwünscht ist. Sollte eine umgangssprachliche Beschreibung
erfolgen, sollte bei der Erstellung dementsprechend gründlich auf die gleichen Gesichtspunkte geachtet werden. Im fertigen System sollen dann alle
produzierten Versionen gleichzeitig laufen, und erkannt werden, welches bei
abweichenden Ergebnissen das korrekte ist.
Um überhaupt ein Multiversionssystem zu unterstützen, muss jedes Programm die Fähigkeit besitzen, zusammen mit anderen Programmen gleichzeitig ausgeführt zu werden und einen Vektor mit Vergleichs-Daten zu
erzeugen (comparison vector, c-Vektor), der an spezifischen Stellen im Programmablauf ausgegeben wird (cross-check points, cc-Points).
Das Verfahren an sich wurde insbesondere von Prof. Algirdas Avizienis der
UCLA untersucht, und im Laufe der Forschungen wurden im hier betrachteten Modell drei grobe Untereinheiten identifiziert (siehe auch Fig. 1):
• Dem Prozess, in dessen Lauf die anfängliche Spezifikation entwickelt
sowie die Unabhängigkeit der Entwicklerteams garantiert sein soll (Nversion Programming Process, NVP)
171
NVP
Execution Environment (EE)
NVS 1
Hilfsfunktionen
NVS 2
...
EntscheidungsAlgorithmus
NVS N
Figure 1: Ablauf eines Schrittes in der NVX
• Dem Produkt, also den einzelnen Implementationen mit den benötigten
Fähigkeiten zur Ausgabe des c-Vektors an den cc-Points (N-version
Software, NVS)
• Die Umgebung, in der die Implementationen ablaufen sollen, und die
die Einrichtungen zum Vergleichen und Auswerten der c-Vektoren und
darauf basierend Entscheidungs-Algorithmen zur Verfügung stellt (NVersion Executive, NVX).
2.1
NVP
Der N-Version Process soll es ermöglichen, N ≥ 2 funktional identische
Programme basierend auf derselben Spezifikation unabhängig zu erzeugen.
Dabei sollen so weit wie möglich verschiedene Programmiersprachen, Umgebungen, Werkzeuge und Algorithmen verwendet werden. Es wird angenommen, dass dadurch in mehr als einem Programm gleichzeitig auftretende
Fehler vermieden werden. Selbst wenn mehrere der Programme fehlerhaft
arbeiten, soll so verhindert werden, dass alle diese Programme dieselbe Ausgabe liefern. Dies würde dem Entscheidungsalgorithmus die Arbeit erschweren.
172
2 Methodik der Multiversionsprogrammierung
Weiterhin müssen die einzelnen Programmierteams voneinander isoliert arbeiten. Es existiert ein “Communications & Documentations Protocol”,
das genau den Informationsfluss der einzelnen Teams steuert und beim
Auftreten von gemeinsamen Fehlern ermöglicht, die Ursache im Falle eines
Kommunikations-Lecks nachzuvollziehen. Innerhalb der Teams sollten natürlich weiterhin bewährte Software-Entwicklungsprozesse eingesetzt werden,
um maximale Qualität zu erzielen. Um den gesamten Prozess durchsetzen zu
können, ist ein Koordinations-Team nötig, welches die Spezifikationen bereitstellt, die Protokolle definiert, den Entwicklungsprozess erklärt und auf
eventuelle Anfragen oder Unklarheiten reagiert. Auch diese Abläufe müssen
formal dokumentiert werden, um bei Auftreten von Fehlern Transparenz zu
ermöglichen.
2.2
NVS
Die Spezifikation der herzustellenden Software ist die Ausgangssituation
der Erzeugung von N-Version Software. Sie muss vollständig und eindeutig sein, und dennoch eine möglichst breite Menge von verschiedenen
Implementationen zulassen. Fehler darin werden sich auf alle der produzierten Versionen auswirken, und somit dem gesuchten Ziel genau entgegenwirken. Zur Sicherheit ist es möglich, mehrere verschiedene Spezifikationen eines einzigen Benutzer-Anforderungs-Dokumentes in formellen
Spezifikations-Sprachen anzufertigen, und diese automatisch auf Äquivalenzt
prüfen zu lassen. Treten Unterschiede auf, sind an denjenigen Stellen vermutlich Unklarheiten aufgetreten.
Es kann explizit festgelegt werden, inwiefern sich die Entwicklungs der einzelnen Varianten unterscheiden müssen. Beispiele wären Erfahrung und Ortslage der Entwickler, Programmiersprachen und -methoden, Entwicklungsumgebungen, Testverfahren oder auch bestimmte Algorithmen und Datenstrukturen. Weiterhin muss für den Ablauf innerhalb einer NVX geregelt
werden, welche Funktionen implementiert werden, und was für Eingaben sie
erlauben. Insbesondere muss natürlich definiert sein, an welchen Stellen des
Programmablaufs cross-check points zu absolvieren sind.
2.3
NVX
Die N-Version Executive soll es ermöglichen, die einzelnen Implementationen zu einer Multiversions-Spezifikation auszuführen, die dabei entstehenden Ergebnisse zu vergleichen, und schließlich über einen Algorithmus eine
Entscheidung über die Wahl des korrekten Ergebnisses zu treffen. Die
NVX ist allgemein gehalten, soll also für unterschiedliche Spezifikationen
173
nutzbar sein. Sie sollte simpel, schnell und verlässlich sein. Eine SoftwareImplementation ist möglich, eine Hardware-Variante ist aber zur Sicherheit
vorzuziehen.
Für den Fall N = 2, falls also im Falle eines Fehlers absolut nicht feststellbar ist, welche Version richtig arbeitet, kann zumindest ein sicheres Herunterfahren des Systems oder ein Revertieren auf einen bekannten korrekten
Status eingeleitet werden.
2.4
Recovery Block Approach
Ein etwas anderes Verfahren, dass ebenfalls die Verlässlichkeit erhöhen soll,
ist der Recovery Block Approach. Auch dafür werden mehrere Versionen
eines Programms konstruiert. Anstatt jedoch alle Varianten gleichzeitig
laufen zu lassen, um dann über das korrekte Ergebnis abzustimmen, wird
während der Laufzeit eine Art Abnahme-Test durchgeführt: Die erste Variante wird durchlaufen und das Ergebnis auf Konsistenz überprüft. Werden
keine Fehler festgestellt, werden die Ausgabe-Daten für die nächsten Schritte
im System verwendet. Tritt im Abnahme-Test jedoch ein Fehler auf, so
wird mittels eines Caches das System auf den Punkt vor Aufruf der Variante
zurückgesetzt, und eine weitere Variante gestartet. Dieser Ablauf kann theoretisch mehrmals stattfinden.
Auf weitere Details dieser Methode soll hier nicht weiter eingegangen werden.
Es ist jedoch offensichtlich, dass von ähnlichen statistischen Annahmen wie
bei Multiversions-Programmierung ausgegangen wird, und somit die Ergebnisse, die im Folgenden vorgestellt werden, auch für den Recovery Block
Approach relevant sind.
3
Experiment
Um die der Multiversionsprogrammierung zu Grunde liegenden Annahmen
zu untersuchen, wurde ein Experiment durchgeührt, welches Implementationen einer einzigen Spezifikation verschiedener Entwickler gegeneinander
testet. So wurde versucht festzustellen, ob eine in Kapitel 2 beschriebene
Methodik auch zu tatsächlicher Unabhängigkeit der Fehlerquellen führt.
Fortgeschrittenen Studenten der University of Virginia (UVA) und der University of California at Irvine (UCI) wurde aufgetragen, basierend auf derselben Spezifikation ein Programm zu schreiben. Um so realitätsnahe wie
möglich zu arbeiten, wurde als Test-Produkt ein Raketen-Abwehr-Programm
gewählt – ein derartiges Programm wurde tatsächlich einmal von einer Luftfahrtgesellschaft entwickelt und ist auf Grund seiner sicherheits-kritischen
174
3 Experiment
Eigenschaft ein sinnvoller Kandidat für fehlertolerante Programmierung.
Dieselbe Problemstellung wurde bereits in anderen Experimenten als Ausgangsbasis für Untersuchungen benutzt, unter anderem bei der NASA. Dies
hatte den Vorteil, dass viele wärend des Experimentes auftauchenden Probleme, wie zum Beispiel in der Spezifikation, schon dort untersucht und behoben wurden. Ausserdem existierte bereits eine ausgiebigst getestete und
untersuchte Implementation des Programmes, die als fehlerfrei angenommen
wurde, und somit zum Feststellen von Fehlern in anderen Implementationen
genutzt werden konnte.
3.1
Voraussetzung
Als Eingabe erhält das Programm Daten aus einer Radar-Anlage. Während
des Programmablaufs werden dann ein “Conditions Met Vector” aus 15
boolschen Elementen(CMV), eine “Preliminary Unlocking Matrix” aus 15x15
boolschen Elementen(PUM), ein “Final Unlocking Vector” aus 15 boolschen
Elementen(FUV), und schließlich ein boolsches Endergebnis, ob ein Abfangprotokoll eingeleitet werden soll oder nicht, generiert.
Für das Funktionieren des Programmes ist dabei nur das Endergebnis von Bedeutung; für die in diesem Experiment betrachteten Zusammenhänge aber
sind auch die Zwischenergebnisse wichtig, um daran eventuelle Fehler des
Programms erkennen zu können, die sich auf Grund anderer Eingaben jedoch nicht auf die simulierten Fälle auswirken. Die Berechnungen laufen
folgendermaßen ab:
Die Eingabe-Daten bestehen aus bis zu 100 verschiedenen 2-dimensionalen
Punkten, die auf 15 “Launch Interceptor Conditions” (LICs) geprüft werden müssen. Dort soll zum Beispiel geprüft werden, ob sich eine Menge an
Radar-Reflektionen alle innerhalb eines Kreises eines bestimmten, als Parameter übergebenen Radius befinden. Ist eine der Bedingungen erfüllt, so
wird das ihr zugehörige Element des CMV auf “Wahr” gesetzt, ansonsten auf
“Falsch”. Basierend auf dem CMV wird mit Hilfe der “Logical Connector
Matrix” (LCM) dann die PUM berechnet. Die LCM enthält Boolsche Funktionen, die Paare der LICs durch ein AND oder OR verknüpfen kann. Dabei
werden nicht alle möglichen Paarkombinationen verwendet. Schließlich wird
dann jede Zeile der PUM untersucht: Sind alle Elemente der Zeile entweder
“Wahr” oder nicht ausgefüllt, so wird das zugehörige Element des FUV auf
“Wahr” gesetzt. Schließlich wird das Endergebnis genau dann auf “Wahr”
gesetzt, wenn alle Elemente des FUV “Wahr” sind.
Die Studenten wurden auf die Programmiersprache Pascal festgelegt, die beiden Universitäten benutzten jedoch unterschiedliche Compiler und Rechnersysteme. Ansonsten wurden die Teilnehmer vom Sinn der Aufgabe inMethoden der empirischen Softwaretechnik
175
formiert und dementsprechend gebeten, bezüglich des Experimentes keinen
Kontakt untereinander zu haben. Es wurde ihnen jedoch freigestellt, jede
beliebige unabhängige Wissensquelle zu nutzen, auch wenn dabei zweifellos
Überschneidungen auftreten würden – dies schien realistisch im Vergleich
zu kommerziellen Projekten. Im Falle von Fragen wurde E-Mail benutzt,
um eine gut dokumentierte und bewusste Informationsübermittlung zu ermöglichen. Probleme in der Spezifikation wurden dabei an alle Programmierer weitergeleitet.
Da bei einigen der Berechnungen auch Fließkommazahlen benutzt wurden,
musste aus praktischen Gründen der Computer-Arithmetik bei allen Vergleichen eine eingeschränkte Präzision benutzt werden. Dies sollte verhindern,
dass in Randfällen die Programme unterschiedliche Ergebnisse lieferten, obwohl an sich korrekt gearbeitet wurde. Zu diesem Zweck wurde eine Funktion
zur Verfügung gestellt. Den Entwicklerteams wurden 15 Datensätze zu eigenen Testzwecken zu Verfügung gestellt, und bei der Fertigstellung des Programms ein Abnahme-Test bestehend aus 200 für jedes Team einzeln zufällig
generierten Datensätzen durchgeführt.
Die Programme wurden dann jeweils den gleichen einer Millionen Testfällen ausgesetzt. Diese waren zwar zufällig generiert, beschrieben aber eher
ungewöhnlichere Fälle, die im echten Betrieb nicht in kurzer Zeit in so großen
Mengen auftreten. Dementsprechend sollten sich auch viele Randfälle darin
befinden. Die Anzahl Testfälle sollte in etwa einer 20-jährigen Nutzungsdauer
entsprechen.
Die von den einzelnen Versionen produzierten Ausgaben wurden dann mit
denen des von der NASA implementierten Programmes verglichen, um die
tatsächliche Anzahl fehlerhafter Ausgaben festzustellen.
3.2
Ergebnisse
Die Ausfallrate ist in Tabelle 1 dargestellt. Neben sechs Implementationen,
die fehlerfrei arbeiteten, arbeiteten weitere 17 Implementationen in 99,9 %
der Testfälle korrekt. Aus Tabelle 2 ist ersichtlich, wie häufig es vorkam,
dass mehr als eine Version bei der gleichen Eingabe eine fehlerhafte Ausgabe
geliefert hat.
Man könnte vermuten, dass die Gruppen der jeweils gleichen Universität stärkere Fehlerkorrelation besitzen, als die aus unterschiedlichen
Universitäten. Studenten der gleichen Universität haben einen ähnlicheren
Wissenshintergrund und neigen somit möglicherweise zu ähnlichen Entwicklungsmethoden, und auch ähnlichen Fehlern. Erstaunlicherweise war dies
nicht der Fall. Tabelle 3 zeigt die Korrelation von Ausfällen bezüglich der
Versionen der verschiedenen Universitäten.
176
3 Experiment
Version Anzahl Ausfälle P[Erfolg]
1
2 0,999998
2
0 1,000000
3
2297 0,997703
4
0 1,000000
0 1,000000
5
6
1149 0,998851
71 0,999929
7
8
323 0,999677
53 0,999947
9
10
0 1,000000
554 0,999446
11
12
427 0,999573
13
4 0,999996
1368 0,998632
14
Version Anzahl Ausfälle P[Erfolg]
15
0 1,000000
16
62 0,999938
17
269 0,999731
18
115 0,999885
19
264 0,999736
20
936 0,999064
21
92 0,999908
22
9656 0,990344
23
80 0,999920
24
260 0,999740
25
97 0,999903
26
883 0,999117
27
0 1,000000
Table 1: Ausfälle pro Version
Basierend auf diesen Daten und der Annahme, dass Fehler in den einzelnen
Implementationen komplett unabhängig voneinander auftreten, wurde dann
eine Wahrscheinlichkeitsberechnung angestellt.
Sei pi die Wahrscheinlichkeit, dass Programm i bei der Ausführung einer der
1.000.000 Tests versagt. Die Wahrscheinlichkeit, dass von 27 Varianten alle
bei einem bestimmten Input fehlerfrei arbeiten errechnet sich dann durch
P0 = (1 − p1 ) · (1 − p1 ) · · · (1 − p27 )
Weiterhin berechnet sich die Wahrscheinlichkeit, dass von 27 Varianten genau
eine versagt durch
P1 =
P0 p1
1−p1
+
P0 p2
1−p2
+ ... +
P0 p27
1−p27
Damit ist die Wahrschlichkeit, dass mehr als eine Variante versagt, genau
Pmore = 1 − P0 − P1
Über eine Binomialverteilung lässt sich daraus die Wahrscheinlichkeit berechnen, dass bei n-vielen Testfällen K davon von mindestens 2 Implementationen
fehlerhaft berechnet werden:
P (K = x) = nx (Pmore )x (1 − Pmore )n−x
Da dies eine sehr aufwändige Berechnung ist und n genügend groß ist, kann
approximativ eine Normalverteilung benutzt werden.
177
Anzahl Implementationen mit
Ausfall bei gleichem Input
Häufigkeit Wahrscheinlichkeit
2
553
0,00055100
3
343
0,00034300
4
242
0,00024200
73
0,0007300
5
6
32
0,0003200
12
0,0001200
7
8
2
0,0000200
Table 2: Gleichzeitige Ausfälle verschiedener Implementationen
ζ=
K−n·Pmore
(n·Pmore (1−Pmore ))1/2
Vergleichen wir nun also die experimentell gewonnenen Daten mit der Theorie. Im Experiment wurden 27 Versionen mit einer Million Fälle getestet und
in 1255 Fällen haben mehr als ein Programm gleichzeitig ein falsches Ergebnis
ausgegeben. Wenn wir von Unabhängigkeit im statistischen Sinne ausgehen,
kann obige Formel benutzt werden, um die Wahrscheinlichkeit für das Eintreten dieses Ereignisses zu berechnen. Für n = 1000000, K = 1255 ergibt die
obige Gleichung also ζ = 100 51. Schon bei 2 33 deckt die Normalverteilung
jedoch 99% ab, dass heisst ab diesem Punkt bleiben nur noch Ereignisse mit
Wahrscheinlichkeiten < 1%. Damit ist das Eintreten des Ergebnisses des Experiments dermaßen unwahrscheinlich, dass die Unabhängigkeits-Hypothese
zumindest in diesem Fall mit weit über 99,9% Wahrscheinlichkeit verworfen
werden kann.
3.3
Analyse der Fehlerquellen
Bei der Untersuchung der gewonnen Daten muss sorgfältig zwischen “Programmfehler” und “Programmausfall” unterschieden werden. Programmfehler sind spezifische Stellen im Code, an denen eine zum Erlangen des
Ergebnisses inkorrekte Operation durchgeführt wird. Programmausfall bedeutet, dass das Programm entweder nicht korrekt beendet wird oder nach
der Beendigung ein falsches Ergebnis ausgegeben wird. Ein einzelner Programmfehler kann also durchaus zu mehreren verschiedenen Programmausfällen führen. Insgesamt wurden in allen Programmen zusammen 45 Fehler
festgestellt (siehe Tabelle 4). Jeder einzelne der Fehler wurde untersucht,
behoben, und es wurde gemessen, wieviele Ausfälle er verursachte. Dies ist
in Tabelle 5 dargestellt, wobei die Zahl vor dem Punkt die Nummer des
Programms, die Zahl hinter dem Punkt die Nummer des Fehlers angibt. In
178
3 Experiment
10
11
12
13
14
15
16
17
UCI
18
versions 19
20
21
22
23
24
25
26
27
1
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
2
3
0
0
0 58
0
1
0
0
0 28
0
0
0
0
0 95
0
2
0
1
0 325
0
0
0 52
0 72
0
0
0 94
0 115
0
0
UVA versions
4 5 6 7
8 9
0 0 0 0
0 0
0 0 2 1 58 0
0 0 0 71
1 0
0 0 0 0
0 0
0 0 3 71 26 0
0 0 0 0
0 0
0 0 1 0
0 0
0 0 0 1 29 0
0 0 1 0
0 0
0 0 0 0
1 0
0 0 3 2 323 0
0 0 0 0
0 0
0 0 15 0 36 2
0 0 0 0 71 0
0 0 0 0
0 0
0 0 0 1 94 0
0 0 5 0 110 0
0 0 0 0
0 0
Table 3: Fehlerkorrelationen zwischen Entwicklern von UVA und UCI
einigen Fällen waren auf Grund von unterschiedlichen Compilern, Maschinen
und Speicherzuständen ursprüngliche Ausfälle nun nicht mehr aufgetreten,
konnten aber durch zusätzliche Analyse spezifischen Fehlern zugeordnet werden. In anderen Fällen war das nicht möglich, diese wurden für die weitere
Untersuchung ignoriert.
Viele Fehler waren nur auf eine einzige Version beschränkt, einige andere
traten jedoch in mehreren Versionen auf. Um die tatsächliche Korrelation zu
messen, wurde bei jedem Fehlerpaar aus verschiedenen Programmen mittels
eines statistischen χ2 -Tests die Null-Hypothese überprüft, dass die Fehler
unabhängige Ausfälle verursachen. Im Allgemeinen verwirft man Hypothesen ab einer Fehlerwahrscheinlichkeit von 99,5%. Dies geschah bei 93 aller
945 getesteten Korrelationshypothesen. Bei weiteren 67 Paaren trat zwar
Korrelation auf, doch nicht genügend, um die entsprechenden Hypothesen
zu verwerfen. Bei einer angenommen Wahrscheinlichkeit von 0,5%, dass die
Hypothese grundlos verworfen wird, würden immer noch 93 der Paare korrelieren. Im Folgenden wird dementsprechend von korrelierenden und von
nicht-korrelierenden Ausfällen gesprochen. Einige der verursachenden Fehler
179
Version Fehler
1
1
2
0
3
4
4
0
0
5
6
3
1
7
8
2
2
9
Version Fehler
10
0
11
1
12
2
13
1
14
2
15
0
16
2
17
2
18
1
Version Fehler
19
1
20
2
21
2
22
3
23
2
24
1
25
3
26
7
27
0
Table 4: Fehler pro Version
sollen hier etwas genauer erläutert werden.
Ein typischer nicht-korrelierender Ausfall enstand durch das Auslassen eines
Rückgabewertes bei ganz bestimmten Pfaden durch eine Funktion. Obwohl
dies durchaus zur Compile-Zeit feststellbar ist, wurde von keinem Compiler
auf diesen Fehler hin geprüft. Dies führte zu unberechenbarem Verhalten,
da somit einfach ein nicht-initialisierter Wert zurückgegeben wurde. Dieser
Fehler führte dennoch zu nur 607 Ausfällen.
Andere nicht-korrelierende Ausfälle wurden durch die Angabe des falschen
Indexes in einem Array verursacht. Obwohl das Programm massiv auf Arrays operiert, führte dieser Fehler zu nur 1297 Ausfällen bei einer Million
Testfällen.
An verschiedenen Stellen traten Probleme durch den Vergleich von
Fließkomma-Zahlen mit eingeschränkter Präzision auf. Zum Beispiel wurde
geprüft, ob eine Zahl negativ ist, indem mit 0 verglichen wurde. Zahlen,
die jedoch von der negativen Seite sehr nahe an der 0 heranlagen, wurden
in der Vergleichsfunktion als 0 behandelt, und so wurde ein falsches Ergebnis zurückgegeben. Dieser Fehler wurde nicht nur von den unerfahreneren
Programmierern begangen, sondern auch von einem im wissenschaftlichen
Bereich erfahrenen Entwickler.
Fließkommazahlen bieten allgemein ein schwieriges Problem: Selbst mit
eingeschränkter Präzision können natürlich Rundungsfehler auftreten, so
dass mehrere korrekt-arbeitende Versionen dennoch unterschiedliche Ergebnisse ausgeben. Es wurde festgestellt, dass derartige Fehler unberechenbar sind, und eine Abschätzung von Wahrscheinlichkeiten unmöglich ist.
Insbesondere können auf diese Weise, wenn der Entscheidungsalgorithmus
scheitert, auch Fehler auftreten, die bei einer normalen, einzelnen Implementierung nicht auftreten.
180
3 Experiment
Fehler Verursachte Ausfälle
1.1
2
3.1
700
1061
3.2
3.3
537
1437
3.4
6.1
607
511
6.2
6.3
32
71
7.1
8.1
225
8.2
98
9.1
47
6
9.2
11.1
554
356
12.1
71
12.2
13.1
4
14.1
1297
71
14.2
16.1
28
34
16.2
17.1
201
17.2
76
Fehler Verursachte Ausfälle
18.1
8
19.1
264
20.1
323
20.2
697
21.1
85
21.2
7
22.1
6551
22.2
1735
22.3
1735
23.1
72
23.2
8
24.1
260
25.1
14
25.2
80
25.3
3
26.1
140
26.2
9
26.3
1
26.4
6
26.5
4
26.6
368
26.7
243
Table 5: Ausfälle pro Fehler
Die korrelierenden Ausfälle waren im Allgemeinen deutlich verworrener als
die nicht-korrelierenden. Zum Beispiel wurden zum Vergleich von Winkeln
nur die entsprechenden Cosinus-Werte verglichen. Bei Verwendung echter
reeler Zahlen wäre dies eine gültige Vergleichs-Möglichkeit gewesen, im Rahmen der begrenzten Präzision der verwendeten Maschinen und der zusätzlich eingeschränkten Präzision für dieses Experiment traten aber Abweichungen zum NASA-Programm auf. Dies ist darauf zurückzuführen, dass
die Sinus- und Cosinus-Funktionen an den Minima und Maxima einen sehr
geringen Differenzenquotienten aufweisen, und so beim Vergleich deutlich
verschiedener Winkel innerhalb dieser Grenzwerte ähnliche Funktionswerte
auftreten. Dieser Fehler wurde in 4 der 27 Versionen gemacht, und die Anzahl der Ausfälle lag zwischen 71 und 206. Insgesamt fiel jedoch nur in 8
Fällen mehr als ein Programm gleichzeitig aus.
181
Im zweiten Beispiel handelte es sich um einen Fehler bei der Annahme, wie
ein Winkel von drei Punkten aufgespannt werden kann. Normerweise kann
man genau einen der Punkte als Winkelpunkt betrachten, jedoch nicht in
den Fällen der Winkelgrößen 180 Grad oder 360 Grad: Bei beiden Winkeln
entsteht zwar als Ergebnis eine gerade Linie, die Winkelpunkte sind jedoch
verschieden. Auch hier waren die Auswirkungen sehr unterschiedlich. Eine
Version fiel 231 Mal auf Grund dieses Fehlers aus, eine andere nur 37 Mal.
Beim Ausfall der zweiten Version fiel die erste Version jedoch immer mit aus.
Um etwas systematischer an die Untersuchung zu Gründen für Fehler heranzutreten, wurde versucht, diese zu klassifizieren: Fehler wurden als ”logisch
verwandt” bezeichnet, wenn sie nach Meinung der Autoren auf demselben
logischen Trugschluss basieren, oder zumindest ähnlich sind und sich funktionsmäßig im gleichen Teil der Anwendung befinden. Dies sind natürlich
subjektive Kriterien, die stark vom Verständnis der Anwendung und dem
der Intention der Programmierer abhängig sind.
Eine erste Annahme legt nahe, dass korrelierende Ausfälle durch logisch verwandte Fehler verursacht werden, da bestimmte Teile des Programms komplexer bzw. fehleranfälliger sind, als andere. Einige der Programm-Ausfälle,
z.B. bei bestimmten Winkelberechnungen, bestätigten diese Hypothese. Es
gab jedoch auch einige Ausfälle, die stark korrelierten, aber nicht durch logisch verwandte Fehler entstanden, es musste also noch weitere Ursachen
geben.
Zur weiteren Überlegung wann und warum korrelierende Ausfälle entstehen,
wurde das folgende Model betrachtet: Ein Programm implementiert eine
Funktion, die die Eingabe I auf die Ausgabe O abbildet.
P : I 7→ O
I besteht dabei aus einer Menge von Eingabemöglichkeiten
I = i1 , i2 , ..., in
und O aus einer Menge von Ausgabemöglichkeiten
O = o1 , o2 , ..., on
P ist zerlegbar in eine Menge partieller Funktionen, die jeweils einen
möglichen Pfad durch das Programm darstellen:
P = P1 , P2 , ..., Pm
so dass für jedes Pj , 1 ≤ j ≤ m gilt:
182
3 Experiment
Pj : I[Pj ]− > O[Pj ],
wobei I[Pj ] der Definitionsbereich und O[Pj ] der Wertebereich von Pj
darstellt. Offensichtlich gilt:
I = I[P1 ] ∪ I[P2 ] ∪ ...O[Pm ]
und
O = O[P1 ] ∪ O[P2 ] ∪ ...O[Pm ]
Konkret entsteht ein Fehler also dadurch, wenn eine der partiellen Funktionen Pi fehlerhaft ist, sie also falsch aufgerufen wird oder fehlerhafte Berechnungen anstellt. Bei der Multiversions-Programmierung können dann zwei
Fälle auftreten: Entweder haben die Programme jeweils Fehler in Pfaden
mit disjunktem Definitionsbereich, das heisst, sie fallen nicht gleichzeitig aus.
Im anderen Fall haben die Programme Fehler in Pfaden, deren Definitionsbereiche sich zumindest teilweise überlappen. Dann können die partiellen
Funktionen entweder niemals, manchmal oder immer das gleiche fehlerhafte
Ergebnis ausgeben. In diesem Modell wird klar, dass Fehler nicht unbedingt logisch verwandt sein müssen, um korreliernde Ausfälle zu verursachen.
Aus diesem Grund wurde eine zweite Hypothese aufgestellt, die besagt, dass
Fehler, die korrelierende Ausfälle verursachen, verwandt bzgl. des EingabeBereichs sind. Zwei Fehler werden also auf Grund bestimmter Eingaben
ausgelöst, abgesehen davon, ob die Fehler in den partiellen Funktionen logisch verwandt sind. Bestimmte Eingaben wären also inherent schwieriger zu
verarbeiten, als andere, so dass sich dort an verschiedensten Bearbeitungsschritten Fehler bilden. Aus dieser Hypothese wurde gefolgert, dass korreliernde Ausfälle also auch mit komplett verschiedenen Algorithmen auftreten
können.
3.4
Schlussfolgerung
Die Authoren der Untersuchung schlossen aus den Ergebnissen, das zumindest für das betrachtete Programm die Theorie der Unabhängigkeit zwischen
Fehlern verschiedener Implementationen nicht haltbar ist. Dies bedeutet
nicht, dass die Verlässlichkeit des Systems nicht prinzipiell gesteigert wird,
die Verbesserung ist nur nicht so hoch, wie der Begriff “Unabhängigkeit” im
theoretischen Sinne versprechen würde.
Es sind allerdings weitere Untersuchungen nötig, um eine allgemeinere
Schlussfolgerung ziehen zu können. Insbesondere eine tiefgründige Untersuchung in der Art der am häufigsten auftretenden Fehler wäre dabei hilfreich, da dann gezielt Methodiken zu deren Vermeidung entwickelt werden
183
können.
Die Art Fehler, die nur in einzelnen Versionen vorkommen, werden möglicherweise eher vom Compiler oder bei Testläufen festgestellt. Mehrfach auftretende Fehler dagegen könnten eher auf die Art oder das Verständnis des zu
lösenden Problems zurückzuführen sein, so dass diese nicht leicht durch formale Methoden zu erfassen sind. Einige Teile des Programms sind inherent
schwieriger zu lösen als andere, so dass sich gerade in diesen Teilen eher
Fehler häufen. Nach dem Experiment wurde ein Fragebogen ausgegeben, um
festzustellen, welche Teile des Problems die Programmierer am schwierigsten
fanden bzw. in welchen Teilen sich die meisten Fehler befinden würden. Die
Ergebnisse dieser Befragung deckten sich nicht mit den tatsächlichen Ergebnissen, die Entwickler konnten also die schwierigen und komplizierten Teile
nicht korrekt einschätzen. Es ist also kein leicht zu lösendes Problem, fehleranfälliges Stellen auch nur zu identifizieren, um sie durch weniger anfällige
Programm-Konstrukte ersetzen zu können.
3.5
Reaktionen
Unter Befürwortern der Multiversions-Programmierung gab es teilweise
heftige Reaktionen auf das durchgeführte Experiment, insbesondere von Professor Algirdas Avizienis der University of California Los Angeles (UCLA)
und einigen seiner ehemaligen Studenten. Die für das Experiment verantwortlichen John C. Knight und Nancy G. Leveson haben aus diesem Grund
eine öffentliche Antwort verfasst, in der sie der Kritik widersprechen. Dort
wird insbesondere darauf eingegangen, dass der Großteil der Kritiken nur
Dinge wiederholen, die an anderer Stelle als Hypothese geäußert werden, jedoch nirgendwo empirisch nachgewiesen wurden.
Auch andere Äußerungen scheinen ihrer Meinung nach keinerlei Halt zu
haben. Auf die Kritik, dass die einzelnen Entwicklerteams der Varianten
keine Methoden des Software Engineerings anwandten erwiderten sie, dass
alle Teilnehmer des Experiments sehr wohl mit Software Engineering vertraut
waren und die durchschnittliche Anzahl Fehler innerhalb der Programme
sogar geringer war, als die bei vergleichbaren Studien. Insbesondere vergleichen sie ihre Ergebnisse mit denen anderer Projekte (s. Tabelle 6).
Es ist ersichtlich, dass das von ihnen durchgeführte Experiment von allen
vergleichbaren Versuchen die meisten Fälle betrachtete und dennoch am
wenigsten Ausfälle zeigte. Damit ist jede diesbezügliche Kritik widerlegt.
Insbesondere wurde bei der Untersuchung an der UCLA nicht der tatsächliche Ausfall des Systems getestet, sondern nur auf die einzelnen Fehler im
Programmcode untersucht. Auch wenn also berichtet wurde, dass die Anzahl gleicher Fehler sehr gering war, ist damit nicht erwiesen, dass die Anzahl
184
3 Experiment
Kni/Lev
27
Chen
7
Kelly
18
NASA
20
Anzahl Versionen
Durchschn. Anzahl
Fehler pro Version
1.6
unbek. unbek. unbek.
Simulierte Testfälle
1,000,000
32
100
921,000
Durchschn. AusfallRate pro Version
.0007
unbek.
.27
.006
Durchschn. AusfallRate bei 3 Versionen
.00004
.10
.20
.0002
Statistisch unabh.
nicht
nicht
Verhalten
nein
getestet getestet
nein
UCLA/H
6
1.8
1000
unbek.
unbek.
nicht
getestet
Table 6: Vergleich verschiedener Unabhängigkeits-Experimente
Ausfälle ebenso gering ist. Zu dieser Größe wurden bei diesem Experiment
keine Aussagen gemacht.
Weiterhin wurde häufig kritisiert, dass die die Abnahme-Prozedur nicht rigoros genug war, da nur 200 Tests durchgeführt wurden. Dieser Test ist jedoch
nur als Nebeneffekt des Experimentes aufgetreten, um sicherzustellen, dass
jede Version für den experimentellen Durchlauf geeignet ist. Die eigentlichen
Test-Prozeduren wurden von den jeweiligen Entwicklern selbst durchgeführt
und waren, wie in der obigen Tabelle auch deutlich zu entnehmen ist, durchaus gründlich genug.
Ausserdem wurde bemängelt, dass kein festes Kommunikationsprotokoll
definiert war, so dass dadurch die Unabhängigkeit eingeschränkt wurde.
Knight und Leveson erwiderten, dass im Paper beschrieben wird, dass jede
Kommunikation nur auf bestimmte Weise über E-Mail stattfinden darf, und
desweiteren auch die Gruppen der verschiedenen Universitäten über 3000
Meilen voneinander entfernt waren.
Als weiteren wichtigen Punkt wird die Größe des Programs kritisiert: bei
einem so kleinen Programm gäbe es einfach nicht genügend Möglichkeiten,
Diversifikation zu ermöglichen. Darauf wurde geantwortet, dass dies zwar
ein gültiger Kritikpunkt sei, allerdings jede andere vom Aufwand machbare
Studie die gleiche Problematik bieten würde. Insbesondere sei auf Grund des
großen Aufwands dieses Verfahrens eine Anwendung bei industriell großen
Projekten ( mehr als 500000 Zeilen Programm-Code) gar nicht möglich.
In der Praxis würden daher wahrscheinlich nur kleine, besonders kritische
Programmteile isoliert und so nur auf kaum größere Module MultiversionsProgrammierung angewandt. Desweiteren würden bei größeren Programmen
mehrere Checkpoints nötig sein, bei denen über Korrektheit entschieden wird.
185
Alleine die Reihenfolge, in der diese Checkpoints abgefragt werden, und die
Geschwindigkeit, in der diese erreicht werden müssen, legt eine gewisse Programmstruktur fest und behindert damit die Unabhängigkeit.
3.6
Diskussion
Auch wenn es zuerst erstaunlich erscheint, dass es sogar vorkam, dass 8
Programme gleichzeitig versagten, sollte man doch einige dafür relevanterscheinende Faktoren beachten: Die geschriebenen Programme bestanden
aus zwischen 327 und 1004 Zeilen von Code. Bei einer so geringen
Programmgröße scheint es nicht unwahrscheinlich, dass selbst bei unabhängiger Fehlerentstehung bei 27 Varianten Fehler in denselben Komponenten auftreten. Dies müsste natürlich durch ein ähnliches Experiment mit
aufwändigeren Programmen untersucht werden. Andererseits hat die Vorarbeit durch die NASA und die relativ geringe Größe des hier genutzten
Problems den Vorteil, dass die Spezifikation bereits sehr gut ausgearbeitet
war. Da gerade eine fehlerfreie Spezifikation eine große Bedeutung für die
Unabhängigkeit der Fehler besitzt, war dies eine sehr gute Ausgangsbasis,
die höchstens durch eine Spezifikation in einer formalen Sprache übertroffen
werden könnte.
Es ist allerdings von der Methodik des Experimentes her fragwürdig,
ob eine Einschränkung auf die gleiche Programmiersprache im Sinne der
Multiversions-Programmierung ist. Implementationen in anderen Sprachen
wie z.B. C oder VHDL hätten durchaus ganz andere Programm-Strukturen
aufweisen können, als die in Pascal geschriebenen. Der Fehler, bei dem Funktionsvariablen nicht korrekt initialisiert wurde, wäre zum Beispiel bei einer
anderen imperativen Programmiersprache mit weiterentwickeltem Compiler
abgefangen worden und in einer funktionalen Sprache wohl gar nicht möglich
gewesen.
Die Hypothese, dass Ausfälle nicht nur durch logische verwandte Fehler, sondern an übergeordneter Stelle durch die Natur bestimmter Eingabedaten
verursacht werden, ist, falls sie in anderen Experimenten nicht widerlegt wird,
für die Multiversionsprogrammierung vernichtend. Dies würde zwangsläufig bedeuten, dass man das Problem der Software-Verlässlichkeit mit komplett neuen Methoden als den jetzigen angehen müsste. Jedoch scheint
die Hypothese in der hiesigen Formulierung etwas zu simplistisch. Sie behauptet nur, dass es Unterschiede in der Schwierigkeit der Berechnungen von
Eingabedaten gibt, nicht jedoch, welche es sind und wie sie zu erkennen sind.
Wenn dies überhaupt möglich ist, wäre eine quantitativere Abschätzung wünschenswert.
186
4 Zusammenfassung
4
Zusammenfassung
Offensichtlich ist eine weitere genaue empirische Analyse des Themas
“Multiversions-Programmierung” von Nöten – die hier betrachteten Kritiken
von Avizienis liefern nicht einen einzigen wissenschaftlichen Gegenbeweis
betreffend der Schlussfolgerung von Knight & Leveson und es wird keine
Studie beschrieben, die die von den Kritikern beschriebenen Mängel behebt
und ein anderes Ergebnis liefert. Im Gegentil: Das allgemeine Ergebnis,
dass die Fehler-Unabhängigkeit selbst bei unabhängiger Entwicklung nicht
derartig gegeben ist, wie die Intuition vielleicht vermuten lassen würde, ist
in einigen anderen Experimenten bestätigt worden. Das heisst nicht, dass
ein derartiger Systemaufbau keine höhere Verlässlichkeit bringt, bestimmte
Ausfälle korrelieren aber in verschiedenen Versionen derartig stark, dass das
gesuchte Maß möglicherweise nicht erreicht werden kann.
Ein Aspekt, der allerdings betrachtenswert ist, sind die Ergebnisse der Multiversions-Programmierung beim Einsatz reeler Systeme. Schließlich wird
ein Entwicklungsansatz betrachtet, der tatsächlich in sicherheitskritischen
Systemen verwendet wird. Vermutlich werden bei solchen Systemen jedes
Mal, wenn die Ergebnisse der N Implementationen voneinander abweichen,
die entsprechenden Umstände genauestens protokolliert, so dass dadurch,
zumindest entwicklungsfirmen-intern, sehr viel mehr statistisches Material
zur Verfügung steht, als es in Studien entwickelt werden kann. Insbesondere
ist interessant, in welchen Fällen ein N-Versions-System kritisch versagt
hat – hierbei muss natürlich auch betrachtet werden, ob tatsächlich eine
unabhängige Entwicklung stattgefunden hat. Ein Fall wie die in der
Einleitung beschriebene Ariane-5 Rakete liefert für eine solche Untersuchung
keine nützlichen Informationen.
Die verursachten Kosten spielen natürlich auch eine große Rolle: Ein
einzelnes qualitativ hochwertiges Programm für sicherheits-relevante Anwendung zu schreiben ist bereits teuer. Der hier vorgestellte Ansatz verlangt
jedoch mindestens ein zweites Programmierteam (häufiger wahrscheinlich
auch noch ein drittes), sowie ein zusätzliches Koordinations-Team, um die
zu beachtenden Protokolle festzusetzen. Es werden trotz der bereits redundanten Versionen ja dennoch gute Entwicklungsmethodiken vorausgesetzt,
wie man sie auch von einem kritischen Einzel-Programm gewohnt ist.
Zumindest regte dieser Versuch aber zusätzlich an, sich genauer mit
üblichen Fehlerquellen in der Software-Konstruktion zu beschäftigen.
Bei der Hardware-Entwicklung zum Beispiel sind viele Problem- und
Störungsquellen wohlbekannt, und es existieren Design-Methoden, um die
Wahrscheinlichkeit eines daraus entstehenden Ausfalls zu minimieren. In der
Software-Entwicklung existieren natürlich auch “Best-Practices”-Methoden,
187
diese sind aber deutlich informeller und quantitativ schwierig zu messen.
5
Quellen
Knight, J. C. and Leveson, N. G. 1986. An experimental evaluation of the
assumption of independence in multiversion programming. IEEE Trans.
Softw. Eng. 12, 1 (Jan. 1986), 96-109.
A. Avizienis, ”The Methodology of N-Version Programming,” Chapter 2 of
Software Fault Tolerance, M. R. Lyu (ed.), Wiley, 23-46, 1995.
Brilliant, S. S., Knight, J. C., and Leveson, N. G. 1990. Analysis of Faults
in an N-Version Software Experiment. IEEE Trans. Softw. Eng. 16, 2 (Feb.
1990), 238-247.
Knight, J. C. and Leveson, N. G. 1990. A reply to the criticisms of the
Knight & Leveson experiment. SIGSOFT Softw. Eng. Notes 15, 1 (Jan.
1990), 24-35.
Kalinsky, David.
Design Patterns for High Availability.
//www.embedded.com/story/OEG20020729S0030
http:
Brilliant, S. S., Knight, J. C., and Leveson, N. G. 1989. The Consistent
Comparison Problem in N-Version Software. IEEE Trans. Softw. Eng. 15,
11 (Nov. 1989), 1481-1485.
188
Untersuchungen zur Fehleranalyse
Christoph Briem
Keywords: Fehleranalyse, Fehlerverteilung, Fehleranfälligkeit
Abstract
Diese Arbeit beschäftigt sich mit Studien zur Fehleranalyse, die
Aussagen über die Fehleranfälligkeit bestimmter Kategorien von Softwaremodulen liefern sollen. Mit Hilfe dieser Aussagen könnte man sich
beim Testen und Korrigieren des Codes auf solche Module konzentrieren, die besonders fehleranfällig sind. Dazu werden zunächst Thesen
aufgestellt, die durch empirische Daten untermauert oder widerlegt
werden. Die Vorgehensweisen zur Datensammlung und die Schlussfolgerungen aus der Datenanalyse der einzelnen Studien werden hier
erörtert und miteinander verglichen.
1
Einführung
Um heutige komplexe Softwareprodukte relativ fehlerfrei ausliefern zu können, werden umfangreiche Tests und Reviews des Produkts durchgeführt.
Welche Module eines Softwaresystems dabei wie kosten- und zeitintensiv
getestet und überprüft werden, wird der Erfahrung der Entwickler überlassen. Zuverlässige, wissenschaftlich begründetet Voraussagen, welche Module besonders fehleranfällig sind und damit außergewöhnlich intensiv getestet
werden sollten, können bisher nicht getroffen werden. Diese wären umso
wertvoller, da in den betrachteten Studien auch gezeigt wurde, dass ein
Großteil der Fehler in relativ wenigen Modulen(bzw. Dateien) gebündelt
ist (siehe Kapitel 5.1). Welcher Kategorie diese relativ wenigen, fehleranfälligen Module jedoch angehören(z.B. besonders große, komplexe oder neu
geschriebene Module), ist zunächst nicht bekannt.
Es existieren jedoch einige plausible Hypothesen, die mit empirischen Daten
überprüft werden können. Diese Arbeit versucht, die Ergebnisse von sechs
Studien zu diesem Thema zu vergleichen. Alle versuchen anhand empirischer
Daten, einige Hypothesen zur Fehlerverteilung zu bestätigen oder zu widerlegen. Diese Hypothesen ähneln sich zwar sehr, sind aber auch teilweise
verschieden oder anders formuliert. Dieser Umstand erschwert die Vergleichbarkeit(siehe nächstes Kapitel).
Es werden auch einige interessante Ergebnisse einzelner Studien aufgezeigt,
die in anderen Studien in der Form nicht untersucht wurden und somit nicht
vergleichbar bzw. überprüfbar sind.
2
Vergleichbarkeit der Studien
In den einzelnen betrachtete Studien wurden die unterschiedlichsten Softwaresysteme in ihrer Entwicklung untersucht. Unter anderem unterscheiden
sie sich in den verwendeten Programmiersprachen, der eingesetzten Hardware
und den Branchen, für die die Systeme entwickelt wurden (z.B. Telekommunikation, Raumfahrt). Gemeinsam sind allen Systemen die hohe Komplexität
(mehrere zehntausend bis mehrere hunderttausend Zeilen Code), die sie erst
für Fehleranalysen interessant machen.
Alle Studien setzen verschiedene Methoden zur Datenerhebung und -analyse
ein, weswegen sich die Ergebnisse einzelner Studien zum Teil beträchtlich
unterscheiden. Trotzdem wird hier versucht, die Ergebnisse zu vereinen
und somit Rückschlüsse auf die Allgemeingültigkeit zu erhalten. Wo dieser
Versuch fehlschlägt(z.B. weil eine Hypothese einer Studie in allen anderen
nicht untersucht wurde), werden interessante Ergebnisse später kurz einzeln
190
3 Untersuchte Softwaresysteme und ihre Entwicklungsstadien
vorgestellt. Es ist klar, dass diese Erkenntnisse nicht unbedingt allgemeingültig sind, weil sie von anderen Studien nicht bestätigt wurden.
3
Untersuchte Softwaresysteme und ihre
Entwicklungsstadien
Folgende Softwaresysteme wurden in den sechs betrachteten Studien untersucht:
NASA [1] Das Tool zur Unterstützung der Planung einer Satellitenmission
der NASA wurde hauptsächlich in FORTRAN geschrieben. Fehler wurden in ein Formular eingetragen und dann analysiert.
Ericsson Telecom [4] Telekommmunikationssystem der Ericsson Telecom AB.
Die Studie enthält keine Angaben zur verwendeten Programmiersprache und Hardware.
Ericsson Norway [7] Verteiltes Telekommunikationssystem von Ericsson Norwegen. 64% der Software ist in Erlang, 26% in C und der Rest in anderen Programmiersprachen (u.a. Java, Perl..) geschrieben. Erlang ist
eine funktionale Sprache zur Programmierung nebenläufiger, verteilter
und fehlertoleranter Echtzeit-Systeme. Fehler in diesem System werden
in einer ”Trouble Report- Datenbank” festgehalten, die über ein WebInterface angebunden ist. Diese Datenbank wurde dann automatisch
ausgewertet.
AT&T [2] Software zur Inventurverwaltung bei AT&T, die zu größten Teilen
in Java entwickelt wurde.
Siemens [5] Software zur Kontrolle der PC-Nutzung der Siemens AG. Ältere Teile des Systems sind in Assembler geschrieben, neuere in einer
Hochsprache1 .
Pighin&Marzona [6] Diese Studie betrachtet gleich zwei Softwareprodukte.
Das erste ist eine Managementanwendung, die zweite ist eine Anwendung für den medizinischen Bereich. Beide wurden in C geschrieben
und laufen auf einem UNIX Betriebssystem. Wer diese Anwendungen
entwickelt hat, steht nicht in der Studie.
Jedes Softwareprodukt durchläuft während seines Bestehens verschiedene
Phasen. Jede Studie teilt diese Phasen unterschiedlich ein. Um diese Studien
1
Welche Hochsprache genau verwendet wurde, wird in der Studie nicht angegeben
191
nun vergleichen zu können, werden die Phasen folgendermaßen festgelegt und
alle Angaben der verschiedenen Studien an dieses Schema angepasst, das der
Arbeit von Ostrand und Weyuker [2](AT&T) entnommen ist:
Early-Pre-Release Die früheste Phase, bestehend aus Entwicklung und Modultests.
Late-Pre-Release Die Phase unmittelbar vor Freigabe der Sofware. In dieser
Phase werden die entwickelten Module zu einem System verbunden
(integration), das dann intensiv getestet wird (system testing).
Post-Release Zeitraum nach der ersten (Beta-)Veröffentlichung des Softwareprodukts. Er kann noch in Beta-, kontrollierte und allgemeine Veröffentlichung unterteilt werden.
Es ist bekannt, dass in späten Phasen des Softwarelebenszyklus die Kosten
zur Fehlerbeseitigung extrem steigen. Bei IBM z.B. geht man davon aus, dass
”die Kosten zur Fehlerbeseitigung von einer Entwicklungsphase zur nächsten (Anforderung, Spezifikation, Entwurf, Codierung, usw.) um jeweils
eine Zehnerpotenz steigen.”(siehe [8]) Nach den intensiven Tests im LatePre-Release sind allerdings wenige schwere Fehler im Post-Release- Stadium
einer Software zu erwarten. Die Studien belegen diese Annahme auch.
Neben diesen Phasen einer Softwareversion werden in einigen Studien
auch die Fehlerhäufigkeiten in mehreren Versionen (sog. releases) einer Software miteinander verglichen.
4
Zur Verfügung stehende Daten
Alle Studien setzen empirische Daten zur Fehleranalyse ein. Unabhängig
von der Art der Datensammlung (Auswertung von manuell erstellten Fehlerberichten oder automatische Analyse von Logfiles) konnten bei allen Studien
folgende Fragen durch Auswertung der Daten beantwortet werden:
• Wann trat der Fehler im Lebenszyklus der Software auf? (z.B. EarlyPre-Release)
• Wie groß war das Modul, das den Fehler enthielt?
Zeilen(lines of code, LOC))
(z.B. 100-200
• Wurde das Modul für dieses Softwareprojekt neu entwickelt oder ist ein
schon vorhandenes Modul modifiziert wiederverwendet worden?
192
5 Vergleichbare Thesen und Datenanalysen zur Fehlerverteilung
Daneben wurden von einigen Studien noch andere Daten erfasst, z.B. die
Schwere des Fehlers in einer Skala von eins bis fünf, die benötigte Zeit, um
den Fehler zu beheben, die Art des Fehlers (z.B. Fehler im Design). Da
diese zusätzlichen Daten in den Studien sehr verschieden sind, wird hier auf
einen Vergleich verzichtet. Auf Ergebnisse einzelner Studien wird in Kapitel
6 eingegangen.
5
Vergleichbare Thesen und Datenanalysen zur
Fehlerverteilung
Dieses Kapitel stellt die verschiedenen Hypothesen über die Fehlerverteilung
in einem Softwaresystem vor, die von erfahrenen Entwicklern als plausibel
angesehen werden und zeigt, ob die Studien mit den gesammelten Daten
diese Hypothesen bestätigen oder widerlegen können. Dieses Kapitel behandelt nur Hypothesen, die von mindestens zwei Studien vergleichbar aufgestellt
worden sind. Diese Vorgehensweise erhöht die Chance der Verallgemeinbarkeit und schließt Ergebnisse, die nur für spezielle Softwaresysteme gelten,
weitgehend aus.
Hypothesen und Ergebnisse, die sich nur in einer Studie wiederfinden, werden
im nächsten Kapitel behandelt.
5.1
Pareto- Prinzip der Fehlerverteilung
Zwei Studien(Ericsson Telecom und AT&T) untersuchten, ob die Verteilung
der Fehler dem Pareto- Prinzip folgt: Ein Großteil der Fehler befindet sich nur
in relativ wenigen Modulen, z.B. 80% der Fehler in 20% der Module, weshalb
dieses Prinzip auch 80/20- Regel genannt wird. Man sollte dieses Prinzip
aber nicht an diesen zwei Zahlen festmachen. So folgt die Fehlerverteilung in
der Ericsson Telecom- Studie dem Pareto- Prinzip: 60% der Fehler wurden in
20% der Module gefunden (siehe Abbildung 1), bei AT&T wurde das Prinzip
von einer Veröffentlichung zur nächsten immer deutlicher: Im ersten release
enthielten 10% der Module 68% der Fehler, ab release 10 enthielten 10% der
Module alle gefundenen Fehler. Auch in der Siemens- Studie ist das ParetoPrinzip erkennbar, obwohl es dort nicht so ausgeprägt ist und auch nicht
explizit vom Pareto- Prinzip gesprochen wird: 45% der Fehler befanden sich
in nur 10% des Codes. Über alle Studien betrachtet kann man also relativ
sicher von einer 60/20- Regel bei der Fehlerverteilung ausgehen.
Wenn sich also die meisten Fehler auf wenige Module beschränken, wäre es
sehr nützlich, Regeln zu haben, die diese wenigen, sehr fehleranfälligen Module identifizieren, so dass sie intensiver getestet werden könnnen. Ob gewisse
193
Figure 1: Paretoverteilung beim Ericcson Telecom- Projekt Quelle: [4]
Regeln bzw. Hypothesen durch empirische Daten untermauert werden können, wird im Folgenden erörtert.
5.2
Große vs. kleine Module
Eine weitverbreitete Ansicht ist, dass große Module, d.h. mit vielen tausend
Zeilen Code, deutlich fehleranfälliger sind als kleine. Aus diesem Grund
werden Programmierer seit Jahrzenten angehalten, Module möglichst verhältnismäßig klein zu halten. Auch Objektorientierung und Modularisierung
arbeiten darauf hin.
Um diese Hypothese zu untersuchen, werden die Module nach ihrer Größe
in Klassen eingeteilt (z.B. 0-100 LOC, 100- 200 LOC,...) und dann die absoluten Fehler und die Fehler pro 1000 Zeilen (kilo lines of code, KLOC) für
jede Klasse bestimmt. In diesen Daten versucht man eine Tendenz zu erkennen.
Die Annahme lässt sich nach der Datenauswertung erstaunlicherweise nicht
mehr halten. Die Anzahl der Fehler pro 1000 Zeilen Code steigt nicht mit der
Größe der Module. Bei manchen Studien2 fällt diese sogar. Es lässt sich nur
mutmaßen, wieso dieser Effekt auftritt. Einige Studien haben gezeigt, dass
viele Fehler im Interface-Teil eines Moduls, egal ob groß oder klein, auftreten
und da der restliche Teil des Moduls fehlerfreier ist, sinkt die Fehleranzahl
pro 1000 Zeilen Code mit der Größe des Moduls. Außerdem werden große
2
194
NASA, AT&T
Figure 2: Punktwolken der Modulgröße(in LOC) gegen die Fehlerrate(in
Fehler/LOC) Quelle: [4]
Module mehr getestet, überwacht und überprüft. Weiterhin sind Fehler in
kleinen Modulen leichter zu finden, wobei die großen Module eventuell noch
Hunderte von Fehlern enthalten, die unter Umständen niemals auftreten, da
Teile des Moduls Spezialfälle behandeln sollen, die in der Praxis (während der
Tests und nach der Veröffentlichung) niemals aufgetreten sind. Man sollte
allerdings nicht in Versuchung kommen und aus diesen Ergebnissen schließen,
dass ein Softwaresystem weniger Fehler enthält, wenn es aus besonders großen
Modulen besteht. 30 große Module lassen sich mit hohem Test- und ReviewAufwand sicher noch relativ fehlerfrei halten, während das bei 300 großen
Modulen sicher unmöglich ist.
Wie wichtig standardisierte und anerkannte Analysetechniken auf dem
Gebiet der Fehleranalyse sind, zeigt die Tatsache, dass die Ericsson TelecomStudie in dieser Frage überhaupt keinen Trend hinsichtlich der Fehlerhäufigkeit in Modulen unterschiedlicher Größe sieht und die anscheinend starken
Ergebnisse bei dem NASA- System aufgrund ”unangemessener Analysen” zustande gekommen seien. Sie unterstreichen das mit einem Diagramm, in dem
sie die Codelänge eines Moduls gegen die Fehlerrate auftrugen (siehe Abbildung 2). Tatsächlich lässt sich in diesem Fall kein Trend erkennen.
195
Studie
Große Module enthalten mehr Fehler
NASA
widerlegt
Ericsson Telecom
nicht widerlegt (keine Tendenz)
Ericsson Norway
nicht widerlegt (keine Tendenz)
AT&T
widerlegt
Siemens
widerlegt
Table 1: Ergebnisse einzelner Studien zur ersten Hypothese
5.3
Wiederverwendete vs. neuentwickelte Module
Die Wiederverwendung von Modulen aus früheren Softwareprojekten soll Entwicklungszeit und -kosten sparen und gleichzeitig die Anzahl der Fehler der
Software klein halten, da die alten Module schon länger getestet und im
Einsatz sind und somit nahezu fehlerfrei sein sollten. Fast alle Studien3 ,
die diese Frage untersuchten (u.a. AT&T, NASA, Ericsson Norway), kamen zu dem Schluss, dass ältere Module weniger Fehler enthalten als neu
geschriebene. Auf der anderen Seite zeigte sich bei dem NASA- Projekt, dass
das Beseitigen der Fehler in Modulen, die aus anderen Projekten stammten,
viel mehr Aufwand benötigte als bei Modulen, die für das betrachtete Projekt neu geschrieben wurden. Vor allem Fehler, die aus missverstandener
oder ungenügender Anforderungsspezifikation entstanden waren, ließen sich
später nur mit großem Aufwand beheben. Dieses Ergebnis unterstreicht die
Wichtigkeit einer korrekten und vollständigen Spezifikation eines Softwareprojekts.(siehe auch Kapitel 6.3) Ein weiterer Grund, warum ältere Module
schwerer zu warten sind, könnte sein, dass Entwickler der alten Module nicht
mehr zur Verfügung stehen oder der verantwortliche Programmierer Probleme hat, seinen eigenen Code zu verstehen und den Fehler entsprechend
zu beseitigen. Deswegen wurde sogar die Frage gestellt, ob es sich lohnt,
alte Module wiederzuverwenden oder ob die Kosten zur Beseitigung der
Fehler in diesen Modulen die Kosten für die Neuentwicklung übersteigen.
Diese Frage muss sicherlich differenzierter betrachtet werden: Standardmodule (z.B. Bibliotheken), die so gut wie gar nicht verändert werden müssen,
müssen sicherlich nicht immer neu geschrieben werden. Andere Module, von
denen ein Großteil des Codes umgeschrieben werden muss und die eventuell
schon unübersichtlich programmiert worden sind, sollten angesichts dieses
Ergebnisses der Studie sicherlich neu geschrieben werden.
3
Nur Pighin und Marzona konnten keinen Unterschied zwischen alten und neuen Modulen feststellen.
196
Studie
Neuentwickelte Module enthalten
mehr Fehler als wiederverwendete
NASA
bestätigt
Ericsson Norway
bestätigt
AT&T
bestätigt
Pighin&Marzona
nicht bestätigt
Table 2: Ergebnisse einzelner Studien zur zweiten Hypothese
5.4
Komplexe vs. einfache Module
Bevor man untersucht, ob komplexe Module potentiell mehr Fehler enthalten
als vergleichsweise einfache, muss man zunächst ein vernünftiges Komplexitätsmaß finden. Einige Studien benutzen hier die McCabe- Metrik4 , die als
Anzahl der Entscheidungen in einem Programm (z.B. if) + 1 definiert ist.
Dieses simple Komplexitätsmaß wird von den Autoren der Ericsson TelecomStudie angezweifelt. Sie verwenden stattdessen das Produkt aus der McCabeund der sog. SigFF- Metrik, die als die Anzahl von Signalen definiert ist,
die von dem Modul verändert oder neu erstellt werden. Die Komplexität
nach der SigFF- Metrik lässt sich sogar schon zur Entwurfszeit bestimmen,
während man mit der Bestimmung nach McCabe bis zur vollständigen Implementierung warten muss. Dafür gestaltet sich die Berechnung nach SigFF
etwas komplizierter.
Fast alle Studien, die nur die McCabe- Metrik benutzten, konnten keinen
Zusammenhang zwischen der Komplexität und der Fehleranfälligkeit eines
Moduls feststellen. Obwohl die durchschnittliche Komplexität bei großen
Modulen stark anstieg, stieg, wie schon vorher beobachtet, die Zahl der Fehler
pro 1000 Zeilen nicht an. Nur Pighin und Marzona konnten bei ihren Projekten beobachten, dass Module, die sie als besonders fehleranfällig betrachteten
(sog. faulty files 5 ), eine etwas höhere (im Bereich von 10-15%) zyklomatische Komplexität hatten. Auch die Ericsson Telecom- Studie konnte mit einer
anderen Metrik (McCabe * SigFF) einen leichten Zusammenhang herstellen,
d.h. Module mit hoher Komplexität laut Metrik enthielten auch viele Fehler
(siehe Diagramm 3). Eine Standardmetrik hat sich anscheinend in der Fehleranalyse noch nicht durchgesetzt. Die McCabe- Metrik scheint nur bedingt
geeignet.
4
Die McCabe- Metrik wird auch zyklomatische Komplexität genannt
Als faulty files werden Module bezeichnet, deren Fehleranzahl größer ist als ein Drittel
der durchschnittlichen Fehleranzahl
5
197
Figure 3: Kumulierter Anteil aller Fehler gegen den Anteil der Module,
nach Größe geordnet. Quelle: [4]
Studie
Komplexe Module enthalten verwendete Metrik
mehr Fehler als einfachere
NASA
nicht bestätigt
McCabe
Ericsson Telecom
schwach bestätigt
McCabe * SigFF
Ericsson Telecom
nicht bestätigt
McCabe
Pighin&Marzona
schwach bestätigt
McCabe
Siemens
nicht bestätigt
McCabe
Table 3: Ergebnisse einzelner Studien zur dritten Hypothese
198
5.5
Frühe vs. späte Produktstadien
Je näher der Auslieferungszeitpunkt eines Produkt rückt, desto weniger
Fehler sollte es enthalten. Die meisten Fehler müssten schon während der
Entwicklung und den einzelnen Testphasen beseitigt worden sein. Spätestens
wenn das Produkt den Betastatus verlässt, sollte es frei von schwerwiegenden
Fehlern sein.
Diese Annahme lässt sich durch Studien belegen. Bei dem AT&T- Produkt
z.B. enthielten vor der ersten Veröffentlichung in der ”Early-Pre-Release”Phase noch 36% aller Dateien Fehler, in der ”Late-Pre-Release”- Phase waren
es noch 18%; nach der ersten Veröffentlichung war das Produkt fehlerfrei. Bei
Ericsson Telecom enthielt die Software vor Veröffentlichung noch 1598 Fehler,
nachher wurden noch 71 weitere Fehler entdeckt. Das sind 20 mal weniger
als vor der Veröffentlichung.
Eine weitere häufig geäußerte Annahme ist, dass Produkte, die schon in
höheren Programmversionen vorliegen, d.h. die schon seit vielen releases
verbessert, gepflegt und weiterentwickelt werden, ausgereifter sind und aus
diesem Grund weniger Fehler enthalten. So galt Windows 1.0 als nahezu
unbenutzbar, während Windows 3.1 schon in vielen produktiven Systemen
eingesetzt worden ist. Offensichtlich wurden ”Kinderkrankheiten” früher Versionen in späteren beseitigt.
Das zeigt sich auch bei der AT&T- Software. Vor allem in der ”Early-PreRelease”- Phase treten weniger Fehler auf. Vor der fünften Veröffentlichung
enthielt das Produkt in dieser Phase noch in 12% der Dateien Fehler. Vor
dem dreizehnten Release waren es nur noch 3%, obwohl sich die Gesamtzahl
sowohl der Files als auch der Codezeilen mehr als verdoppelt hat. An der
Software scheinen also nur noch Erweiterungen vollzogen worden zu sein,
deren Implementierung nicht so fehleranfällig war wie noch in früheren Versionen.
5.6
Nachhaltigkeit von Fehlern in bestimmten Modulen
Es gibt sehr unterschiedliche Meinungen zu der Frage, ob Module, in denen
schon vor der Veröffentlichung viele Fehler gefunden worden sind, auch später
besonders viele Fehler enthalten. Argument für diese Annahme könnte sein,
dass Module mit vielen entdeckten Fehlern deutlich komplexer sind als andere
und somit auch weitere schwerwiegende Fehler enthalten. Dagegen spricht
die Vermutung, dass Module, in denen viele Fehler gefunden wurden, auch
sehr intensiv getestet worden sind und somit nicht mehr so viele enthalten.
Die Ericsson Telecom- Studie bestätigt die letztere Vermutung. Dort traten
vor einer Veröffentlichung 77% der Fehler in Modulen auf, die nach der VeröfMethoden der empirischen Softwaretechnik
199
fentlichung keine Fehler mehr enthielten. Auch die Wissenschaftler bei AT&T
kommen zu einem ähnlichen Ergebnis. Dort betrug der Prozentsatz der ”latepre-relase”- Fehler in Modulen, die nach der Veröffentlichung fehlerfrei waren,
je nach Programmversion 72 bis 94%. Auf der anderen Seite ist die Anzahl
der Fehler nach der Softwareveröffentlichung so gering, dass verlässliche Aussagen im Grunde nicht getroffen werden können.
Eine weitere interessante Frage könnte sein, ob Module, in denen schon in
früheren Softwareversionen viele Fehler entdeckt wurden, auch in späteren
Veröffentlichungen besonders fehlerhaft waren. Die zwei Studien6 , die diese
Frage behandeln, kommen zu dem Schluss, dass dies wirklich der Fall zu
sein scheint: ”once faulty, ever faulty” (Pighin&Marzona [6], Seite 6). Bei
AT&T z.B. wurde dazu für jede Version eine Hitliste der 20 fehlerhaftesten
Module aufgestellt und miteinander verglichen. Von einer Veröffentlichung
zur nächsten blieben 17 bis 54% der Top 20- Module in dieser Hitliste. Also
scheint es sich durchaus zu lohnen, sich beim Testen der neuen Version auf
Fehlerergebnisse der vorherigen Versionen zu stützen.
6
Nicht vergleichbare Ergebnisse einzelner Studien
6.1
AT&T
In dieser Arbeit wurde nicht nur untersucht, wo und wieviele Fehler auftraten, sondern auch wie schwer die Fehler in einer Skala von 1 (kritisch) bis
5 (kosmetisch) waren. Systemkritische Fehler der höchsten Kategorie traten
nur in 1,6% der Fälle auf, 14,5% wurden in die Kategorie 2 eingestuft. Der
Hauptanteil (81%) wurde als mittelschwerer Fehler angesehen. Der Rest entfiel auf die zwei untersten Kategorien.
Es ist sicherlich schwer, aus diesen Erkenntnissen Methoden zur Fehlerbeseitigung oder gar -verhütung zu entwickeln. Anscheinend werden sehr schwere
Fehler schon beseitgt, bevor sie überhaupt in das System eingespielt werden
und dort als zu beseitigende Fehler erfasst werden, da der Programmierer so
lange Fehler in einem Modul beseitigt, bis es lauffähig ist. Und da die Kategorie 1 nur solche Fehler umfasst, die die Lauffähigkeit des Systems komplett
behindern, muss nicht lange getestet werden, um zu bemerken, dass sich ein
Fehler im System befindet. Dagegen sind mittelschwere Fehler, die nicht
sofort augenfällig werden, erst nach intensivem Testen zu finden und schleichen sich auch schneller und häufiger in ein System ein, da es nach ersten
Testläufen zunächst zu funktionieren scheint. Also entspricht dieses Ergebnis
den Erwartungen, kann aber wohl zu keinen Methoden zur Fehlerbeseitigung
6
200
AT&T und Pighin & Marzona
6 Nicht vergleichbare Ergebnisse einzelner Studien
entwickelt werden.
6.2
Siemens
In dieser Studie konnte auch die Auswirkung der Verwendung verschiedener
Programmiersprachen auf die Fehlerraten beobachtet werden. Drei verschiedene Sprachen wurden zur Entwicklung des betrachteten Systems eingesetzt:
• Assembler
• Columbus-Assembler (eine Assembler-Sprache, die um Kontrollmakros
wie if, then, else, end erweitert wurde)
• eine nicht näher spezifizierte Hochsprache
Die Fehlerraten(Fehler pro Codezeilen) waren bei Assembler ungefär genauso
hoch wie bei der Hochsprache. Dabei muss man allerdings beachten, dass
eine bestimmte Aufgabe in der Hochsprache in weniger Zeilen programmiert
werden kann als in Assembler. In diesem Fall war diese Verhältnis ungefähr
2 zu 1 zugunsten der Hochsprache, so dass man sagen kann, dass Module,
die in der Hochsprache geschrieben wurden, ungefähr halb so viele Fehler
enthielten wie vergleichbare Module in Assembler. Interessant sind nun
die Auswirkungen des Einsatzes von Columbus-Assembler auf die Fehlerrate. Hier scheint die Verwendung von einfachen Kontrollstrukturen den Entwicklern zu helfen, Fehler zu vermeiden: Die Fehlerrate sinkt im Vergleich
zum einfachen Assembler-Code. Abbildung 4 verdeutlicht dies: Unabhängig
davon, wie viele Zeilen Code in dem Softwareprojekt geändert wurden, blieb
die Fehlerrate der Module, die in Columbus-Assembler geschrieben wurden,
unter der für den einfachen Assembler-Code.
6.3
6.3.1
NASA
Verschiedene Fehlertypen
Beim NASA- Projekt wurde auch die Art des Fehlers erfasst und ausgewertet.
12% der entdeckten Fehler waren dabei Schreibfehler (z.B. falsch geschriebene
Bezeichner). Ebenso erwähnenswert ist die Tatsache, dass allein 6% der
Fehler auf das falsche Korrigieren vorheriger Fehler zurückzuführen waren.
Anscheinend wurde bei der Fehlerkorrektur nicht genug Sorgfalt an den Tag
gelegt oder andere Gründe, die schon in Kapitel 5.3 angesprochen wurden (z.B. fehlende Kenntnis der Programmarbeitsweise), führten zu diesem
Ergebnis.
201
Figure 4: Anzahl der veränderten Codezeilen(DLOC) gegen die Fehlerrate
im Siemens-Projekt Quelle: [5]
Nimmt man nun diese beiden Fehlertypen aus der Betrachtung heraus, wurden folgenden Fehlerklassen gewählt:
• Anforderungen falsch oder missverstanden
• Funktionale Spezifikation falsch oder missverstanden
• Designfehler, der mehrere Komponenten betrifft
• Design- oder Implementierungsfehler, der nur eine Komponente betrifft
• Externe Umgebung falsch beachtet
• Fehler, der die falsche Benutzung der Programmiersprache bzw. des
Compilers betrifft
Wie man nun in Abbildung 5 sehen kann, machen Fehler in den Anforderungen und vor allem in der formalen Spezifikation den Großteil der
Fehler aus. Wenn man die Schreibfehler aus der Betrachtung herausnimmt,
sind 63% der Gesamtfehlerzahl solche Fehler. Auch hier wird wieder
deutlich, wie wichtig eine korrekte und vollständige formale Spezifikation
eines Softwareprodukts ausmacht. Wer in dieser frühen Phase der Softwareentwicklung spart, handelt sich mit hoher Wahrscheinlichkeit später
besonders hohen Aufwand und damit Kosten zur Fehlerbeseitigung ein.
Dieser Umstand kann das komplette Entwicklungsprojekt unter Umständen
202
Figure 5: Aufschlüsselung der Fehlerursachen im NASA- Projekt
Quelle: [1]
sogar komplett scheitern lassen.
6.3.2
Aufwand zur Fehlerbeseitigung
Außerdem wurde noch der Aufwand zur Fehlerbeseitigung in der Studie
untersucht. Wie in Kapitel 5.3 schon angedeutet, ist der Aufwand bei
wiederverwendeten Modulen größer: Wie Abbildung 6 zeigt, ging ein
Großteil der Berichte über Fehler, deren Beseitigung zwischen einem und
drei Tage dauern, auf Kosten von wiederverwendeten Modulen (15 zu 3%).
Berichte über Fehler, deren Beseitigung sogar mehr als drei Tage dauert,
verteilen sich ungefähr gleich auf wiederverwendete und neue Module (12
zu 15%). Die möglichen Schlussfolgerungen zur Wiederverwendung von
Modulen wurden schon in Kapitel 5.3 diskutiert.
6.3.3
Einteilung der Fehler in abstrakte Klassen
Die Autoren der NASA- Studie teilten alle Module in verschiedene abstrakte
Klassen ein:
203
Figure 6: Fehlerbeseitigungsaufwand Quelle: [1]
• Initialisierung
• Kontrollstruktur
• Interface
• Daten
• Berechnung
Nun untersuchten sie, in welchen Modulklassen die meisten Fehler auftraten.
Dabei unterschieden sie zwischen neuentwickelten und modifizierten7 Modulen und teilten auch die Fehler nochmal folgendermaßen auf:
Eingabefehler Diese Fehler resultieren aus einer vorhanden falschen ausführbaren Anweisung. Ein solcher Fehler wäre z.B. A = B * C, wobei
das ’*’ ein ’+’ hätte sein müssen. Der Operator existiert also, ist aber
falsch.
Auslassungsfehler Diese Fehler ergeben sich, wenn ein Element überhaupt
nicht vorhanden ist, obwohl es für den korrekten Programmablauf
vorhanden sein müsste. Ein Beispiel für einen solchen Fehler wäre
die Anweisung A = B, obwohl es richtigerweise A = B + C hätte heißen
müssen. Ein weiteres Beispiel ist das Auslassen vergessener Parameter
bei einem Funktionsaufruf.
7
204
”Modifiziert” ist in diesem Fall gleichbedeutend mit ”wiederverwendet”.
Eingabefehler Auslassungsfehler
Summe
neu
mod.
neu
mod.
neu mod. Summe
Initialisierung
2
9
5
9
7
18
25(11%)
Kontrollstr.
12
2
16
6
25
8
36(16%)
Interface
23
31
27
6
50
37
87(39%)
Daten
10
17
1
3
11
20
31(14%)
Berechnung
16
21
3
3
19
24
43(19%)
28%
36%
23%
12%
115 107
222
64%
35%
Table 4: Fehlerverteilung in einzelnen Modulklassen Quelle: [1]
Wie man nun Tabelle 4 entnehmen kann, scheinen Interfaces besonders
fehleranfällig zu sein, unabhängig davon, ob es sich um neugeschriebene
oder wiederverwendete Module handelt. Kontrollstrukturen sind in neueren
Modulen eher fehlerhaft. Das könnte nach Meinung der Autoren daran
liegen, dass in die alten Module schon mehr Test- und Debug- Zeit investiert
wurde. Andererseits enthalten wiederverwendete Module überdurchschnittlich viele Fehler in der Inititialisierung und in den Datenstrukturen. Ein
Grund dafür könnte sein, dass diese Module für ihren neuen Zweck noch
nicht richtig angepasst worden sind. Anpassungen an neue Aufgaben sind
meist in den Datenstrukturen und weniger in den Kontrollstrukturen nötig.
Außerdem müssen in wiederverwendeten Modulen eher Anweisungen verändert als hinzugefügt werden, was die geringere Anzahl an Auslassungsfehlern
erklären könnte.
Aus diesen Erkenntnissen könnte man nun Regeln für das Testen und Debugging von Modulen aufstellen. Leider fehlen hier die Bestätigungen durch
andere Studien.
6.4
6.4.1
Ericsson Telecom
Anteil der fehlerhaften Module am Gesamtsystem
Wie nun schon ausführlich behandelt, enthalten relativ wenige Module einen
sehr hohen Anteil an Fehlern (siehe Kapitel 5.1). Eine Erklärung dafür
könnte sein, dass diese wenigen Module besonders groß sind und somit zwar
die Anzahl der Module mit vielen Fehlern klein ist, nicht aber die Anzahl der
Codezeilen. Dagegen spricht die Tatsache, dass die Fehlerrate in größeren
Modulen nicht unbedingt ansteigt(siehe Kapitel 5.2). Trotzdem könnten ja
Module so groß sein, dass sich die hohe Anzahl der Fehler doch auf sehr viel
205
Codezeilen verteilt.
Deswegen haben die Autoren der Ericsson Telecom- Studie untersucht, wie
groß der Anteil der fehlerhaften Module an der Gesamtgröße des Systems
ist: Sie betrachteten dabei zwei releases des gleichen Softwareprodukts.
Beim ersten release machten die fehlerhaften Module nur 12% der Größe des
Gesamtsystems aus. Beim zweiten release befanden sich 60% der Fehler in
Modulen, die nur 6% des Gesamtsystems ausmachten. Weiterhin machten
Module, die 78% der Gesamtfehler enthielten, nur 10% des Gesamtprodukts
aus. Damit ist gezeigt, dass der Großteil der Fehler sich in relativ wenigen
Programmzeilen befindet.
6.4.2
Stabilität der Fehlerraten im Softwarezyklus
Da der Studie Daten für zwei aufeinanderfolgende releases zur Verfügung
standen, konnten die Fehlerraten der einzelnen Entwicklungs- und Betriebsphasen miteinander verglichen werden. Dabei wurden die Phasen folgendermaßen aufgeteilt:
• Funktionstest (FT)
• Systemtest (ST)
• Systemintegration (SI)
• Programmbetrieb (OP)
FT ST
SI
OP
Release 1 3,49 2,60 0,07 0,20
Release 2 4,15 1,82 0,53 0,20
Table 5: Fehlerraten in den vier Test- und Betriebsphasen Quelle: [4]
Wie man der Tabelle 5 entnehmen kann, sind die Fehlerraten bei beiden
releases relativ vergleichbar. Nur die Systemintegration fällt etwas aus dem
Rahmen. Trotzdem kann man wohl sagen, dass der Entwicklungsprozess
bezüglich der Fehlerrate stabil ist.
206
6.5
Pighin&Marzona
Diese Studie benutzt zwei Klassen von Dateien8 , die auf diese Weise von
anderen Studien nicht definiert wurden. Somit sind auch die Ergebnisse, die
sich aus dieser Definition ergeben, nicht mit anderen vergleichbar.
Heavy Files(HF) Für die Bestimmung der heavy files werden die Dateien
nach enthaltener Fehlerzahl absteigend geordnet. Alle Dateien, die in
dieser Rangfolge hinzugenommen werden müssen, damit die Hälfte der
Gesamtfehlerzahl in dem Softwareprodukt erreicht wird, werden zu der
Menge der heavy files gezählt.
Faulty Files(FF) Wie schon in Kapitel 5.4 erwähnt, sind dies jene Dateien,
deren Fehleranzahl größer ist als ein Drittel der durchschnittlichen
Fehleranzahl im gesamten Softwareprodukt.
Mit diesen zwei Definitionen kann man nun die Fehlerberichte gezielt
auswerten und kann die in Tabelle 6 dargestellten Ergebnisse errechnen.
Anteil
Anteil
Anteil
Anteil
Anteil
Anteil
heavy files
heavy files
heavy files
faulty files
faulty files
faulty files
Softwareprodukt
1
2
am Gesamtprodukt
12,5% 18,8%
an der Menge der Files mit mind. 1 Fehler 19,0% 22,0%
an der Menge der faulty files
31,5% 65,8%
am Gesamtprodukt
07,9% 15,1%
an der Menge der Files mit mind. 1 Fehler 12,0% 17,7%
an der Menge der heavy files
20,0% 52,9%
Table 6: Beziehung zwischen faulty files und heavy files Quelle: [6]
Diese Tabelle zeigt, dass es einen gewissen Zusammenhang zwischen den
beiden Definitionen zu geben scheint: Der Anteil der heavy files an der Menge
der faulty files ist bedeutend höher als der am Gesamtprodukt. Daraus könnte man schließen, dass faulty files tendenziell dazu neigen, zu heavy files des
Softwareprodukts zu werden.
So interessant diese Ergebnisse auch sein mögen, sind sie weiterhin mit Vorsicht zu betrachten, da noch keine andere Studie bekannt ist, die die gleichen
Klassendefinitionen verwendet und diese speziellen Ergebnisse auf anderen
Softwaresystemen bestätigt, so dass sie verallgemeinert werden könnten.
8
”Datei” ist in diesem Zusammenhang gleichbedeutend mit ”Modul”.
207
6.6
Ericsson Norway
Wie auch bei der AT&T- Studie (siehe Kapitel 6.1) wurde auch hier die
Schwere des Fehlers erfasst. Leider sind die Skalen nicht vergleichbar, bei der
AT&T- Studie ging sie von 1(kritisch) bis 5(kosmetisch), hier geht sie von
A(schwer) bis C(leicht). Außerdem wird noch zwischen wiederverwendeten
und neuentwickelten Modulen unterschieden. Die Ergebnisse kann man in
Tabelle 7 ablesen.
Schwere
A
B
C
Summe
Wiederverwendet Neuentwickelt Gesamtprozent
160
167
31%
226
261
55%
49
98
14%
435
626
100%
Table 7: Schwere der einzelnen Fehler beim Ericsson Norway- Projekt
Quelle: [7]
Wie man erkennen kann, werden auch hier die meisten Fehler als ”mittelschwer” eingestuft. Der Erwartungswert für Fehler der Schwere A in den
wiederverwendeten Modulen beträgt 134,85, der für die neuentwickelten 190.
Daraus kann man erkennen, dass mehr schwere Fehler bei wiederverwendeten Modulen gemeldet wurden als erwartet. Bei neuentwickelten Modulen
verhält es sich genau andersherum. Als Ergebnis kann man festhalten, dass
wiederverwendete Module dazu tendieren, mehr schwere Fehler zu enthalten
als neuentwickelte.
Gründe für dieses Phänomen sind schwer zu ermitteln. Intuitiv würde man
sagen, dass wiederverwendete Module schon besser getestet sind und sich nur
noch eher mittelschwere Fehler einschleichen. Da dieses Ergebnis noch nicht
durch andere Studien bestätigt wurden, kann es sein, dass es projektspezifisch
ist und nicht verallgemeinert werden kann.
7
Fazit
Obwohl auf dem Gebiet der empirischen Fehleranalyse schon lange geforscht
wird (die älteste Studie ist jetzt schon mehr als 21 Jahre alt9 ), sind auch die
neueren Studien in ihren Ergebnissen nicht sehr überzeugend. Das ist besonders bei der Ericcson Norway- Studie zu sehen: Fünf der zehn aufgestellten
Thesen werden nach der Datenanalyse als ”nicht zurückgewiesen” betrachtet,
9
208
Die NASA-Studie [1] stammt aus dem Jahre 1984.
7 Fazit
d.h. bei der Hälfte der Hypothesen konnte keine eindeutige Aussage über ihre
Richtigkeit erzielt werden. Es existieren einfach zu wenige Studien auf diesem
Gebiet und es haben sich noch keine einheitlichen Richtlinien und Metriken
zur Durchführung und Analyse der Studien herauskristallisiert. Das und die
Tatsache, dass interessante Hypothesen von jedem Autor leicht umformuliert
bzw. geändert werden, machen die einzelnen wissenschaftlichen Arbeiten
schwer vergleichbar.
Es gibt zwar teilweise interessante Ergebnisse in den einzelnen Studien(siehe
Kapitel 6). Dort wurden aber teilweise so unterschiedliche Fehlerklassen
und Analysemethoden eingesetzt, dass eine Verallgemeinerung auf alle Softwaresysteme schwer möglich ist. Dazu müssten andere Studien diese
speziellen Analysen auch einsetzen und bestätigen bzw. widerlegen.
Nun stellt sich die Frage, wieso so wenige Studien auf dem Gebiet der Fehleranalyse existieren. Das erste und vielleicht größte Problem ist sicherlich,
verlässliche Fehlerdaten über ein großes Softwareprojekt zu erhalten. Das
Schreiben von ausführlichen Fehlerberichten ist zeitund somit kostenintensiv. Automatische Datenerhebung mit Hilfe von Logfiles oder Content
Management- Systemen setzt voraus, dass die benutzten Tools diese Auswertung auch unterstützen, z.B. dass sie zwischen Fehlern und anderen Änderungen des Quellcodes (z.B. Implementierungen neuer Funktionen) unterscheiden können. Ein besonders wichtiger Faktor, der Testaufwand für ein
Modul, wird von keiner der hier betrachteten Studien untersucht. Solche
Daten standen einfach nicht zur Verfügung. Erschwerend kommt hinzu, dass
anscheinend wenige Firmen Interesse daran haben, Fehlerdaten ihrer Softwareprojekte mit Wissenschaftlern zu teilen.
Zweitens müssen die erhobenen Daten analysiert und bestenfalls verlässliche
Modelle für die Voraussage von fehlerträchtigen Modulen gefunden werden.
Dies scheint bisher nur teilweise gelungen. Selbst wenn solche Modelle entwickelt worden sind, müssen sie in der Praxis angewendet werden. Dies ist
definitiv noch nicht eingetreten.
Zu den verlässlichen Aussagen, die von allen Studien bestätigt wurden, gehört
die Pareto- Verteilung der Fehler in einem Softwareprojekt. Wie man nun
aber diese besonders fehlerbehafteten Module im konkreten Fall vorhersagen
kann und ob dies überhaupt möglich ist, bleibt weiter relativ offen. Einzig die
Nachhaltigkeit von fehlerhaften Modulen aufeinanderfolgender Softwareversionen kann als anerkannte und halbwegs verlässliche Voraussage angesehen
werden. Alle anderen Hypothesen konnten entweder nicht bestätigt, aber
auch nicht widerlegt werden oder es gab in verschiedenen Studien unterschiedliche Ergebnisse.
In Zukunft müssten sich also konkrete Analysetechniken und Metriken durchsetzen und anhand dieser normierten Methoden einheitliche Hypothesen in
209
möglichst vielen, unterschiedlichen Softwareumgebungen (evtl. noch mit verschiedenen Programmiersprachen) empirisch ausgewertet werden. Dann könnte man vielleicht endlich verlässliche Aussagen treffen, wo sich die meisten
Fehler mit hoher Wahrscheinlichkeit befinden.
References
[1] V.R. Basili and B.T. Perricone. Software Errors and Complexity:
An Empirical Investigation. Communications of the ACM, Vol
27, No 1, Jan 1984, pp. 42-52
[2] T.J. Ostrand and E.J. Weyuker. The Distribution of Faults in
a Large Industrial Software System. In Proceedings of the 2002
ACM SIGSOFT international Symposium on Software Testing
and Analysis (Roma, Italy, July 22 - 24, 2002). ISSTA ’02. ACM
Press, New York, NY, pp 55-64.
[3] Elaine Weyuker, R. Bell and T. Ostrand. Challenges in Predicting the Location of Faults in Large Software Systems.
IEEE/Proc. Workshop on Predictive Software Models (PSM04)
September, 2004.
[4] N.E. Fenton and N. Ohlsson. Quantitative Analysis of Faults and
Failures in a Complex Software System. IEEE Trans. on Software
Engineering, Vol 26, No 7, Jul 2000, pp. 653-661.
[5] K.-H. Möller and D.J. Paulish. An Empirical Investigation of
Software Fault Distribution. Proceedings of IEEE First International Software Metrics Symposium, Baltimore, Md., May 21-22,
1993, pp. 82-90
[6] M. Pighin and A. Marzona. An Empirical Analysis of Fault Persistence Through Software Releases. Proceedings of the 2003 International Symposium on Empirical Software Engineering. p.
206
[7] P. Mohagheghi, R. Conradi, O.M. Killi, H. Schwarz. An Empirical Study of Software Reuse vs. Defect-Density and Stability.
Proc. of the International Conference on Software Engineering
(ICSE’04), Edinburgh, Scotland, UK, 23-28 May 2004, pp.282292.
210
References
[8] P. Steffens. Geschäftserfolg in der Software-Branche hängt
von Menschen und Methoden ab. http://www.innovationsreport.de/html/berichte/informationstechnologie/bericht14924.html. Besucht am 02. Januar 2006
211
Documentation and Source Code
Reading
An analysis of different source code readers
Anbalagan Sonaimuthu
Keywords: Documentation, Source Code reading, Object-oriented technology,
experimentation,Object Oriented Reading Techniques (OORTs), Perspectivebased Reading
Abstract
With the increase in the popularity of software, the need for quality also increases. This is the driving force for the software engineering researchers to investigate technologies that could aid in improving
quality. Software inspections have become or are becoming an important part of the quality assurance effort for software products in
many cases. Inspections are a process whereby software artifacts are
examined by a group of inspectors to ensure that they meet some set
of quality constraints. Inspection is also used to uncover defects in
the artifact. In this paper I have tried to study different inspection
or reading techniques available. Basically I will concentrate on the
following reading technologies that are commonly used.
1. Inspections
2. Scenario Based Reading
3. Perspective Based Reading (PBR)
4. Object Oriented Reading Techniques
5. Defect Based Reading
6. Use-case Based Reading
7. Scope Based Reading
The overall goal of this work is to provide an overview of different reader, classify them, throw some light on different experiment
conducted in this field and finally draw some general conclusion from
them.
1
Introduction
With the increase in the popularity of software, the need for quality also increases. This is the driving force for the software engineering researchers to
investigate technologies that can aid in improving quality. Software inspections have become or are becoming an important part of the quality assurance
effort for software products in many cases. Inspections are a process whereby
software artifacts are examined by a group of inspectors to ensure that they
meet some set of quality constraints. Inspection is also used to uncover defects in the artifact. It is spread into various industrial settings shows the
perceived usefulness of this technology. Earlier, inspection work focused on
improving the quality of the code using inspections, now researchers have expanded inspections, so apart from code, they also cover requirement, design,
test plans and user interfaces.
Before inspections there was the idea of a walkthrough. The walkthrough
could range from simple peer review on one extreme and a formal inspection
of the type we are discussing here on the other extreme. Walkthrough are less
formal and are applied differently in each of the settings, hence the problems
with using walkthroughs is that the number of data collected is usually very
small. The efficiency of defect detection is also quite variable due to this.
Each project environment and product is different in some way or in
other words we can say that they are unique. The application of techniques
and methods on different projects should be expected to vary due to this.
Software development organization differs in many dimensions, for example,
the application domain can vary from entertainment software to educational
software to military support software, or it can be the level of risk inherent in
the project, in some cases, the failure may mean only a little inconvenience,
while with other mission critical applications, it could mean loss of life or
very heavy monitory loss. Though there are some standard methods and
practices for performing inspections, in many cases these methods may need
some variation in some way or the other depending on the application.
214
3 Families of Reading Techniques
2
Reading Scenarios
Software development basically has to generate systems that takes care and
satisfies the user’s needs.There are various documents associated with the
software development like requirement analysis, code and testing plans etc.
During the developmental life cycle these document often require continual
review and modification. In order to verify and validate the software artifacts,
reading is a key activity. In order to remove defects during development,
methods like inspections [8] are considered very effective, inspections rely on
effective reading techniques for success.
As soon as the documents are written we can perform reading, this can be
performed on all documents associated with the software process. Methods
like inspections walk-throughs, reviews etc assume that the given document
can be read effectively, but techniques for reading particular document, such
as test-plans or requirement documents do not exist. In some cases where
the techniques exist, they are seldom taught or practiced.
Reading can be performed on all documents associated with the software
process and can be applied as soon as the documents are written. Most efforts have been associated with methods that simply assume that the given
document can be read effectively (e.g., inspections, walk-throughs, reviews),
but techniques for reading particular documents, such as requirements documents or test plans are still under research.
3
3.1
Families of Reading Techniques
Inspections
There are a wide range of fields which use inspection, this concept is not
unique to software engineering. Depending on the setting, the goal of these
inspection defers. The general goal is to ensure that the artifact is of the
expected quality to be used by the customers of that document. For example
a marketing person have their requirement analysis inspected for feasibility
before passing them along to the prototype development team of an organization. Similarly, software development teams get their software artifacts
inspected before passing along to the next phase of the life cycle.
The concept of inspection was introduced by Fagan [8], since then many
variation has emerged. The main idea behind inspection as defined by Fagan
was that, after completion of a software artifact like requirement document,
design or code, it is submitted for inspection. An inspection consists of multiple steps. Firs of all an inspection team is selected by the inspection leader.
This team is given responsibility of inspecting the document is distributed
215
among these team members. The author of the document provides a contextual information of the document to the team members. The team member
then spends individual time on the document by reading it and get familiar
with it. The inspection leader calls for a second meeting once all of the inspector become familiar with the document. In this meeting the document
is read through and defects are detected by the inspectors, these defects are
collected in a form of list and it is returned to the author. The author finally
either fixes these defects or convinces the inspector about why this is not a
defect.
Many minor changes where suggested and implemented on inspection
since the initial definition by Fagan. Structural change of the meeting, number of meeting participants, elimination of the meetings etc. where some of
the changes that were suggested to the basic inspection process. The overall
goal still remained the same, which is to critically examine a software artifact
to uncover defects that may be present so that those defects are removed before the document is ready to be used by its customer or it is ready to be sent
to the next phase of the software life-cycle. There are many techniques that
has been proposed to improve the inspection meetings, some work has also
been done in helping the inspectors when performing the individual stage of
the inspection. Two such techniques are Perspective Based Reading (PBR)
for the inspection of requirement document and Object Oriented Reading
Techniques (OORTs) for inspection of object oriented design. These techniques will be discussed in section 3.3. and 3.4 respectively.
3.2
Scenario-Based Reading
Software development and analysis techniques need to be well defined, it is
supposed to be context dependent and goal-oriented, and it should demonstrate effectiveness for purpose. The following goals are established for defining reading techniques:
• Flexibility: The technique should be flexible as per the project and
environmental characteristics. For example if the problem domain
changes, the reading technique should also change.
• Reusability: The technique should be reusable, which could be repeated by others. It should be detailed, such that it provides the reader
with a well-defined process.
• Goal Oriented:The technique should be goal oriented, it should see
to it that each reader has a particular purpose or goal for reading the
216
document and the procedure should support that goal. The procedure
can vary from project to project.
• Modularity: The technique should be modular, in such a way that a
particular technique provides a particular coverage of a document and
a combination of different technique provides the coverage to the entire
document.
To determine if and when the technique is most effective, the technique
is studied empirically. In the study, a set of techniques are defined, which is
called proactive process-driven scenarios, it is in the form of algorithms that
readers can apply to traverse the document with a particular emphasis. The
scenarios should fit into the appropriate developmental phase and notation.
It should be associated with the particular document like test plan and the
notation in which the document is written like English text. Several scenarios
must be combined to provide complete coverage of the document as they are
focused, detailed and specific to a particular emphasis or viewpoint.
In their paper [3] the authors have defined an approach to generate a
family of reading techniques based upon operational scenarios as illustrated
in figure 1. In an operational scenario it is required that the reader creates
a model of the product first, and later he answers the questions based on
analyzing the model with a particular emphasis. The types of question and
choice of abstraction will depend on the scenarios like the problem history of
the organization or the goals of the organization in large and the document
that is being read in particular.
Figure 1: Building focused reading technique
Perspective Based Reading and Defect based reading are two different
families of scenario-based reading techniques for requirement documents. In
the following subsections we will have a look at these two reading technologies.
217
3.3
Perspective Based Reading (PBR)
Generic inspection procedure does not help the individual reader in the
preparing for the inspection meeting. A technique called Perspective Based
Reading (PBR) was developed by Basili [5] in 1996 for helping the readers
to perform the individual inspections for requirement. This technique was
based on the fact that throughout the software life cycle there are various
“customers” of the requirement document. The individual inspector is provided with a specific view of the perspective from which the review of the
requirements document is done in such a way that all of these customers were
represented in the review team. The idea is that if different reviewers are
provided with specific view or perspective from which they review the document, then we can achieve a much better coverage of the whole document
when we put together all of them.
In their paper [5] they had defined initial perspectives that are tester, user
and designer. For each perspective, a high level abstraction of the software
artifact is created by the inspector, in the same manner as that the customer
would usually create. The inspector will uncover defects in the process of
creating that software artifact. For example, when the inspector is using the
designer’s perspective, he creates a design plan for the requirements. If there
is a requirement that is not defined in such a way that a design plan can be
created, then the inspector comes across a defect that is uncovered.
As an example, let us consider the procedure for test-based perspective,
when the reader is applying it to a requirement specification document, which
could be as follows:
Reading Procedure: Make up a test or a series of tests for each and
every requirement, which will allow to ensure that the implementation satisfies the requirement. The test suite should be made using the standard test
approach and test criteria. The test suit should be made in such a way that
the following questions are answered:
1. Is all the necessary information available to identify the item being
tested and to identify the test criteria? Based upon the criteria, is it
possible to make up reasonable test case for each of the items?
2. Do we get any contradictory result with another requirement for which
we generate a similar test case?
3. Do we always get a correct value in the correct unit with the test case
we generated?
4. Based on the way the requirement is defined, are there other interpretations of this requirement that the implementor might make? Will
218
this effect the test that has been made up?
5. Is there any co-relation between what we know about the application
and what is specified in the general description, does the requirement
make any sense?
The points listed above are the five example questions which could be
used as the basis by the test-based reader to review the document.
3.4
Defect Based Reading
Researches have developed defect classification schemes, in order to understand the types of defects that occur in the software artifacts better. A
properly specified defect classification schemes can be useful for comparisons
across studies and environment and also for repeatability. Here an attempt
is made to group the defect into classes as per the environment in which
they occur. In the coming subsections we will discuss the classification of
defects and the work done to classify them. In every case, what the defect
classifications will look like will depend on the reason for what the organization classifies. The goals of the organization greatly influence the scope
and specificity of the classification described below. After the related work
is discussed, defect based reading will be described.
3.4.1
Defect Classification Schemes
In order to measure their process with the intent of improving, the organization must classify the defects that are found using it. So the idea of grouping
defects into classes is not a new one, it has been extensively used in fields
other than computer science, like in industry. It can be either a simple classification like only 2 classes namely, major and minor or it can be something
quite elaborate. As described in the previous subsection, the defect classification will highly depend on the reason for which the organization wants
to classify the defect. This classification also depends on the phase of the
software life cycle in which the inspection is going to take place.
So depending on their local environment, many different defect classification schemes have been proposed by researchers. From these classifications,
some are useful for the documents produced throughout the software life
cycle, and others are more specific and they are useful at the documents
from a specific life cycle phase. These classification are mostly with defect
in requirement documents or defects in source code, some classification also
deals specifically with the defect in design documents. The following example
throws some light on the defect classification scheme for requirements.
219
3.4.2
Defect Classification Schemes for Requirement
The study of the evaluation of a requirements document for the on-board
operational flight programm for A-7 aircraft was described in [4] by the authors, which is a complex real time program. They were actual defects which
evolved along with the evolution of the document. A one level classification
scheme with 7 categories was defined by the author. Here the classes were
used to make hypothesis about the commonly made defects.
Clerical - Problems in the documents like typing mistakes, which are relatively quite simple.
Ambiguity - The documents may have more than one meaning which leads
to ambiguity.
Omission - Some facts and figures have been omitted in the document.
Inconsistency - There is inconsistency between two parts of the document.
Incorrect Fact - There is some incorrect fact in the document with respect
to the domain.
Information Put in Wrong Section - Right information is placed in the
wrong section, which may lead to defect.
Implementation Fact not included - Complete information is not given,
some of the information or facts are not included.
Other - The defects which do not fall into any of the above classes.
As we could see in the above subsection, Defect Based Reading focuses
on the defect detection in requirements, or defect detection in source code or
design. The requirement or design is expressed using a state machine notation
called SCR. It is based on different missing classes like ambiguity or omission
or missing functionality etc which we saw in the previous subsection. Defect
based reading was defined for reading documents written in SCR style [10]
which is a formal notion for event-driven process control system and it focuses
of different defect classes as described in the previous subsection. Here three
different scenarios are created which are
1. Data type consistency
2. safety properties
3. ambiguity/missing information
220
An experimental study [4] was done to analyze the defect-based reading, ad
hoc reading and checklist-based reading to evaluate and compare them with
respect to their effect on defect detection rates. The major results which
were found out from this experiment were.
1. There was an improvement of 35% in the performance of scenario based
reading as compared to ad hoc and checklist based readers.
2. Scenarios not only helped reviewers focus on specific defect classes but
also they were more effective at detecting other defects.
3. The effectiveness of checklist and ad hoc based reading was almost the
same.
In order to guide the reader, the defects are categorized and characterized
into a set of questions developed for each defect class.
3.5
Object Oriented Reading Techniques (OORTs)
The primary usage of software inspection in general and scenario-based or
perspective-based inspector in particular, has been in connection with textual artifacts resulting from conventional structured programming methods
like requirements documents or code modules. During its evolution in the
beginning less work had been done in the inspection methods to be used in
graphical form of object oriented artifacts. There are two reason for this.
First is that over the past decade object-oriented development methods replaced conventional structured programming methods as the embodiment of
software development, they are now the approach of choice in most new software development projects. So the inspection methods that are more and
more relevant to the conventional structured methods will become obsolete
as more and more of these methods are surpassed. Second reason is that
though the many beneficial features of object oriented technology, low defect
density is not one of the strong point of this technology. Some empirical studies has even shown that object-oriented artifacts are more error prone than
functional artifacts. One of the reason for this is the lack of comprehensive
reading techniques for inspection in most of the leading object-oriented development. Object oriented methods therefore would benefit quite enormously
with the availability of such techniques. A systematic viewpoint-based inspection approach like perspective-based inspection approach offers a very
good way of accommodating the complexity of object-oriented systems.
As described in the section about PBR, in order to perform the individual
inspection for the object oriented design, the inspectors has to be provided
221
with guidance. Since the requirement and design are actually different representation of the same goal, to see to it that all the system is captured from
the requirement in a consistent way should be the overall goal of the system.
To do this there are two different types of techniques which could be used
namely, horizontal technique and vertical technique. Horizontal technique ensure that the design is internally consistent, so they are the techniques which
are used to compare two different design documents. The vertical technique
is used to ensure that not only the design is consistent with itself but also
it does correctly capture the requirement, hence they are used to compare
the design document back to the requirement and the use cases. For example, there may be the case that the inspector finds that some functionality
described in the requirements does not appear anywhere in the design.
Figure 2: Reading Techniques for Object Oriented Design [14]
Abstraction and Use are the two important models of an Object Oriented
based reading. A model of abstraction is the model of the important information in an artifact and how these information are interrelated and organized.
The model of abstraction are very easy to identify at high level for an Object
Oriented design (as shown in figure 2). The information is described in separate models or diagrams like state machines, class diagrams or interaction
diagrams etc. The model of Use describes the usage of the information in
the artifact to detect the defects. It describes how we use the information.
Also the reviewer should have a general domain knowledge to have a better
understanding of the system that is being built, and to decide weather the
model can be realized. While the general domain knowledge is necessary,
usage of other irrelevant information from other domains should be avoided
from appearing in the artifact since it can lead to ambiguity and hurt the
clarity of the artifact. All artifacts should be analyzed for its self-consistency,
and it should be made sure that it has only one interpretation of the final
system.
222
3.6
Usability Based Reading
Usability or use-case based reading technique aims at checking wether each
object responds back correctly to all the possible ways in which it might be
used. It attempts to address the dynamic nature of Object Oriented systems. It verifies that the correct methods are being called with respect to
the use cases in which the object participates, similarly it also verifies that
the decisions and state changes made within each method are correct and
consistent. Here we basically decide a number of scenarios from the use-case
and examine how the class under inspection deals with these scenarios. We
discover the defects by noticing the erroneous state changes, missing methods, incorrect methods etc. This technique forces the inspector to consider
the context in which an object is used. This technique is applied by the inspector by taking each use-case in turn and device a series of brief scenarios
based on the preconditions, exception found in the use-case and success and
failure conditions. To guide the inspector throughout the interactions that
the scenarios have with the code under inspection, a sequence diagram is
used. Due to this the inspector :
• Has to become familiar with the code which is under inspection,
• He should be able to identify the state of the system that will make a
particular scenario to occur,
• As a result of the scenario, he should be able to identify the expected
change of state and outputs from the classes under inspection,
• By tracing the message calls between objects he should be able to follow
the scenario through the sequence diagram.
This technique is meant to be complementary to other reading approaches
since there is a possibility that some part of the class will not be checked due
to the reason that they are not involved in that particular use-case.
3.7
Scope-Based Reading (SBR)
Here we find a particular technique which allows the user to better understand
the document in order to use it in constructing another document. The
the idea is to use the reading technique for learning about Object-Oriented
framework in order to reuse it. There are two techniques which are developed
to do the above tasks, one is hierarchically based and the other one is example
based.
223
4
The Data and Experiments
In this section we will discuss about the different experiments conducted to
test the effectiveness of the source code readers. A short overview of how the
experiment was conducted and a brief analysis of the data obtained in the
experiment immediately follows the overview.
4.1
4.1.1
Defect-Based Reading Experiment
Experiment at University of Maryland
Experiments were conducted at University of Maryland on defect-based reading study [4]. A comparison and evaluation was made between Defect-based
reading, ad-hoc reading and checklist based reading. Their effect on fault
detection effectiveness were evaluated and compared. In the study, a blocked
subject project was replicated twice in two semesters using 48 students of
University of Maryland. The experimental was done in two pass, on the first
pass there were more ad-hoc and checklist readers, many of them (not all)
where moved to the second pass for defect-based reading.
Results from the experiment: With this experiment they found out
that the performance of defect-based readers was much better than ad-hoc
and checklist readers. The defect based readers were not only able to focus
on specific fault classes but also they were effective in detecting other faults,
and finally the effectiveness of both checklist reading and ad hoc reading were
almost the same.
4.1.2
Real-time track control for railway companies
A variation of the traditional inspection was done by the authors in [12].
Here the author had investigated the benefits gained with the inspection
being performed on multiple independent inspections of same requirement
document instead of doing only one inspection. The document they studied
was for a “real-time track control for railway companies”. The author of the
document was an expert in the domain of railroad engineering, and so he
had made some actual defects during the creation of the document. Apart
from the defect made by him, some new defects were introduced by the
researchers to balance the number of different defect classes. There was
two high level classes with subclasses in each of these high level classes.
They wanted to find out wether the new inspection process affected on how
inspector performed in finding these classes of defects.
Missing or Incorrect Information
224
4 The Data and Experiments
Missing Functionality or Missing Feature There has been some omission of the
information describing internal behavior of the system
Missing Interface There has been omission of the information about how the
system communicates with the external interfaces i.e., objects outside
the system.
Missing Performance There has been some omission of performance specifications or it has been described in an untestable way.
Missing Environment There has been an omission of information about the
external hardware, software, databases or personnel which will be interacting with this system.
Wrong or Inconsistent Information
Ambiguous Information There in an ambiguity in the definition of an important term, it is either not defined at all or there are multiple interpretation of that term.
Inconsistent Information There is a contradiction between the two parts of the
same document.
4.1.3
Scenario-based reading on Cruise control system and water
level monitoring system
A study of scenario-based reading was done by authors Porter and Basili
[11]. Here each inspector executed a series of steps to discover a particular
class of defect. They were inspecting the domains of the requirements of
cruise control system and a water level monitoring system. They also had a
similar defect classification as done by the previous section by [12] which was
discussed above. In their experiment the authors were comparing the adhoc reading technique and checklist reading technique with the then newly
developed technique of scenario-based reading. They developed scenarios in
such a way that each scenario targeted a specific class of defect. Here just
like in the previous subsection, the defect classification was in two levels. The
first level was very abstract and the second one was more in detail and it was
more useful in the actual defect detection. Both these levels drew greatly
from the studies mentioned above. The author combined these classification
to fit to their environment.
Omission
1. Missing Functionality: There has been an omission in the information describing the desired internal operational behavior of the system
225
2. Missing Performance: There had been an omission of information
describing the desired performance specification or it is described in
such a way that it is unacceptable for acceptance testing.
3. Missing Environment: There has been an omission of information
describing the required hardware, software, database, or personnel environment in which the system will run
4. Missing Interface: There has been an omission in the information
describing how the proposed system will interface and communicate
with objects outside the scope of the system
Commission
1. Ambiguous Information: There is ambiguity in the information provided, an important term, phrase or sentence which is essential to the
understanding of the system has either been left undefined or it is defined in such a way that can cause ambiguity.
2. Inconsistent Information: There is a contradiction in two or more
sentences, they either directly contradict with each other of they or
they express actions that cannot both be correct or cannot both be
carried out.
3. Incorrect or Extra Functionality: There are extra or incorrect
functionality which under specified conditions these sentence asserts a
fact that cannot be true.
4. Wrong Section: Some essential information are misplaced in the document.
Results from the above two experiments: In the above experiment
the authors where investigating a variation on the traditional inspection
methodologies. Firstly, instead of only one inspection being performed on the
requirement document, they tried to investigate the pros and cons of having
multiple and independent inspections for the same requirement document.
They found that multiple independent inspectors where able to perform significantly better than single inspector. Secondly with this experiment, they
proposed multiple level of classes for defect. With their work they tried to
demonstrate the feasibility of such reading technique and improving those
techniques based on the results of empirical studies.
226
5 Classification
4.2
Perspective-Based Reading Experiment
In their study on perspective-based reading [5] they evaluated and analyzed
perspective-based reading with respect to its effect on fault detection effectiveness in the context of the inspection team. They defined and studied
three types of perspective based reading techniques. They were tester-based,
designer-based, and user-based. The effectiveness of the perspective-based
reading was evaluated on both domain-specific and generic requirements documents. These documents had been constructed expressly so that the generic
portion could be replicated in a number of different environment and the
domain-specific part could be replaced in each new environment. This was
useful because it helped in improving the local to a particular environment
while they were easily able to combine the generic parts of multiple studies.
This experiment was done in two runs, based on the feedback from the
first run, they made some changes in the experimental design and did an
improved second run. In the first run they found it necessary to include
some more training sessions as the subjects were not completely familiar
with both the documents and the techniques involved in the experiment.
They allowed less time for each review of the document as they found out
that the subjects tended to tire in longer sessions. They also shortened some
of the documents so that they could reach a size that could be realistically be
expected to be checked in an experimental and time-constrained settings.By
making the above changes they had their second run.
Results from the experiment: The major result of this experiment
was that there was an improvement in time and individual scores when
perspective-based reading was applied to generic document. With this experiment they also showed that with perspective-based reading technique the
relative effort spent on fixing defects was better.
5
Classification
The evolution of the understanding on reading technologies is through empirical studies and experiments. Many different experimental designs have been
used to understand the insight into the effect of different types of reading
technologies, we had seen some of them in the previous section. The classification of reading families can be broadly divided into two spaces, namely, the
“Problem Space” and the “Solution Space”. The problem space models the
problems that can be addressed by reading and the solution space models the
specific solutions that has been provided to date for the particular problems.
A further specialization of each of the space is done as shown in the
rightmost column of the Figure 4. For example in the problem space a
227
reading technology can be applied for analysis which is a general goal or
high level goal, this analysis is more specifically done for detecting defect
which is a specific goal in a design which is a document which are written in
the form of OO Diagram. Just like problem space, solution space is further
subdivided, here it consists of Reading Families and Reading Techniques as
shown in the lower rightmost part of the Figure 4. Each family is associated
with particular goal or document or software artifact. This is also associated
with the notion in which the document is written. Each technique within the
family is
1. Tailorable, depending on the project and environmental characteristics, these techniques could be tailored as per requirement.
2. Detailed, here it is well documented so that the reader has to follow
a well-defined set of steps.
3. Specific, the reader has a particular goal for reading the document
and the has procedures that support the goal.
4. Focused, the technique provides a particular coverage of the document
and combination of techniques provides the coverage for the entire document.
Construction and analysis activities are the integral part of the software
life cycle. For example, the testing phase is responsible for creating testplan document and also it is responsible for analysis of its quality. Since
both construction and analysis are two parts of the same phase, from the
analysis technologies we can learn about the construction technologies. So
the reading activity can be divided into “Reading for Analysis” and “Reading
for Construction” at high level goal. The next two subsection deals in detail
about these two parts of high level goal.
5.1
Reading for Analysis
Reading for analysis helps us to understand the type of defects that we make
and the nature and structure of the product, hence it is important for the
product quality. They attempt to answer the following question: “With the
given document how do I access the various qualities and characteristics?”
Reading for Analysis is quite useful in assessing the quality of the document
and also it can provide insights into better developmental practices and techniques. It can be applied to various documents throughout the life cycle of
the software.
228
5 Classification
There are different families of reading techniques which are collectively
know as scenario-based reading techniques. These techniques requires the
reader to create an abstraction of the product and based on that abstraction
of the product the reader is required to answer question with a particular
emphasis or the role that the reader assumes. Since there will be different
roles the reader assumes there will be different abstraction and question set,
and each reading technique can be based upon a different set of these abstraction and questions. The kind of document being read or the problem
and history of the organization or the goals of the organization decides the
type of question set and the choice of abstraction.
Figure 3: Reading Techniques for Analysis [2]
Figure 3 shows the Problem space and Solution space of the reading
for analysis part of the reading technique. In the solution space there are
different families of scenario based reading technique. The remaining part of
this subsection describes the different types of reading techniques. The first
type in the family is called defect based reading technique. This technique
focusses on a model of the requirement using a state machine notion. There
are different classes, and each model views are focused on specific class. Some
of these classes are data inconsistency, incorrect functions and ambiguity
or missing information. A set of question which is used in check-list for
evaluating the correctness and reliability of the requirement documents is
used to generate the analysis question.
Perspective based reading technique is another member of the family of
scenario-based reading technique. It focusses on the different product perMethoden der empirischen Softwaretechnik
229
spective. For example reading from the perspective of a developer or the
end user or the tester or service engineer and hardware engineer etc. Various
kinds of requirement errors like omission, ambiguity, incorrect fact, inconsistency etc are the basis of generating the analysis question. The questions
thus developed can be used to discover these errors from the perspective of
the assumed reader of the document.
Another family of techniques which comes under scenario based reading
is Usability-based reading. This focuses on the usability of the software,
weather its an expert or a novice. The analysis questions are generated by
focusing predominately on the usability point of view of the system.
5.2
Reading for Construction
Reading for construction basically deals with what a system is capable of
doing, what a system does and what capabilities exists or do not exist in the
system. They attempt to answer the following question: ”With the given
existing system, how can I understand on how to use it as part of my new
system?”. It helps us in abstracting the important information in the system.
This is useful both in maintenance and building a new system using the
reusable components and architecture of the existing system.
Though Reusing an existing system or library increases quality and productivity it does not provide the default system behavior, it provides a
functionality at a low level and it forces the developer to provide the interconnections between the libraries. The reusability which is allowed by
object-oriented technology framework has to follow a pre-defined class hierarchy which the developers should strictly follow, also they have to follow
the framework of object interaction and thread of control framework by object oriented technology. Hence in a framework-based development there is
a learning curve so it has to be first learnt and then adapted to the specific
requirement of the application. It has been found that the effort of learning the framework and include a reusable class libraries is less than doing
it from the scratch. In the following two subsections we will discuss about
the two different types of this framework, namely, White-Box and Black-Box
framework.
5.2.1
White-Box Framework
A white-box framework is a set of interacting abstract classes that captures
the invariants in the problem domain. Here the source code of the class are
accessible to the programmer. Due to this it is possible for the programmer to
derive application-specific class from the base class through inheritance and
230
5 Classification
by completing or overriding their methods. To learning curve for a whitebox framework is same as that of its construction, since the user must have
a detailed framework knowledge of the codes involved.
There are two different reading techniques which are defined under whitebox framework to build a new application. They are (a) system-wide reading
technique and (b) task-oriented reading technique. Both techniques have
access to the same source of information and they both look at the run-time
behavior and static structure of the framework. They mainly differ from the
focus of the learning process. The system-wide technique focuses more on the
big picture than the detailed task to be completed, hence it covers the whole
system, and task-oriented technique focuses more on the details of individual
task of the system. Programmers attempt to gain a broad knowledge of the
framework design with the system-wide reading technique.
5.2.2
Black-Box Framework
A black-box framework on the contrary to the white-box framework, is customized by selecting parameterizing and configuring a set of components that
provide the application specific behavior. They allow an application to be
created by composing objects rather than programming. Here the programmer is not able to see the source code of the components, and the interface
between the components can be defined by protocol. Hence the user only
needs to understand the external interface of the components and does not
have to bother about the code of the component. This framework is considered easier than white-box framework since the programmer does not need
to look into the source code. A better documentation and training is a must
because developers cannot look into code to know what is going on.
The only experiment so far in testing the construction branch of the tree is
the study of scope-based reading. Unlike the analysis branch the hypotheses
here are related to finding a particular technique that allows the user to
better understand the document for use in constructing another document.
231
Figure 4: Reading Techniques Classification [2]
Figure 4 shows the overall taxonomy of reading families that we had
discussed till now. The upper part of the tree (over the dashed horizontal
line) models the problems that can be addressed by reading.
6
Conclusion
In this report we tried to have an overview of the different techniques of
source code reading, also we had a classification of these source code readers.
We had a look at many experiments that were conducted on source code
readers at different Universities and research institutes. As we had seen
in the classification part, the reading could be done for construction or for
analysis of the document, and both of them co-exists.
We also had a look at the families of reading techniques that were used,
most of the work in reading has so far been focused on three main families of
reading techniques namely, perspective-based reading, defect-based reading
and scope based reading. As we could find from the experiments that were
conducted in these reading family one could derive that, each technique had
its own strength and weakness in terms of the faults they can help in uncovering. The effectiveness of the technique solely depend on the nature of the
programs to be more precise, the nature of faults in those programs. There
also seem to have the trace of fundamental weakness in each of the technique
when applied individually. A combination of these techniques showed general
improvement.
232
References
Finally these techniques are more formally defined and it has been proved
by experiments that they are very much effective than the simple walkthrough
or simple peer review and these techniques have evolved from the days of
structural programming to the current Object Oriented framework.
References
[1] Atkinson, C. and Laitenberger, O. Generalizing Perspective-based Inspection to handle Object- Oriented Development Artifacts. Fraunhofer
Institute for Experimental Software Engineering
[2] Basili, V. R. et al: Studies on Reading Techniques. Experimental Software Engineering Group, University of Maryland at College Park
[3] Basili, V. R. Evolving and Packaging Reading Techniques Through Experimentation. Experimental Software Engineering Group, University of
Maryland at College Park
[4] Basili, V. R., Porter, A., Votta, L. Comparing detection methods for
software requirements inspections: a replicated experiment. IEEE Transactions on Software Engineering, vol. 21, no. 6, 1995.
[5] Basili, V. R., Green. S., et.al: The empherical investigation of
Perspective-Based Reading, Empirical Software Engineering Journal, I.
[6] Briand et al. An Experimental Comparison of the Maintainability
of Object-Oriented and Structured Design Documents. IESE-Report
008.96/E, December 1996.
[7] Dunsmore, A. et al. Practical Code Inspection for Object Oriented Systems. Computer Science Department, Strathclyde University
[8] Fagan, M. Design and Code Inspections to Reduce Errors in Program
Development. IBM Systems Journal 15, 3 (1976): 182-211
[9] Foote, B. and Jonson, R. Designing Reusable Classes. Journal of ObjectOriented Programming June/July 1988
[10] Heninger, Kathryn L. 1980, Specifying Software Requirements for Complex Systems: New Techniques and Their Application. IEEE Transactions on Software Engineering SE-6: 2-13.
233
[11] Porter, A., Votta, L. G. Jr. and Basili, V. R. 1995. Comparing Detection
Methods For Software Requirements Inspections: A Replicated Experiment. IEEE Transactions on Software Engineering, 21(6)
[12] Schneider, G., Martin J. 1992 An experimental study of fault detection in
user requirement documents. ACM Transaction Software Eng Methods
1(2).
[13] Travassos, G. H. et al. Detecting Defects in Object Oriented Designs
Using Reading Techniques to Increase Software Quality. University of
Maryland at College Park Accepted Paper at the OOPSLA, Denver,
Colorado, 1999.
[14] Travassos, G. H. et al: Reading Techniques for OO Design Inspections.
University of Maryland at College Park
[15] Empirical Investigation of Perspective-Based Reading. A Replicated Experiment. IESE Technical Report, 1997.
234
Softwaremetriken
Thomas Franken
1
Einleitung
In der Softwaretechnik ist es heutzutage aus ökonomischer und
wissenschaftlicher Sicht Konsens Messverfahren bei Softwareentwicklungsprozessen einzusetzen, um bedeutende Merkmale und Kenngrößen zur
Planung und Steuerung zu ermitteln. In diesem Kontext haben viele Unternehmen die Wichtigkeit einer genauen Kostenkontrolle mit deren Hilfe
sie sich mit anderen Unternehmen vergleichen können. Um das zu bewerkstelligen benötigt man prezise Modelle und Metriken, die eine Analyse der
Qualität und Produktivität von Softwareentwicklungsprozessen erlauben.
Diese Seminararbeit stellt angefangen von den klassischen bis zu neueren
Ansätzen die bekanntesten Softwaremetriken zusammen und untersucht
diese Messverfahren hinsichtlich ihrer metrologischen Eigenschaften. Dabei
kommen, wie in anderen Ingenieurwissenschaften schon seit langen üblich,
grundlegende Konzepte aus der Maßtheorie zu Einsatz. Außerdem werden
hier Modelle zur Validierung von Softwaremetriken erläutert und angewandt.
Desweitern beleuchtet das Kapitel 3 den Standard ISO/IEC 14143 zur Messung des funktionalen Umfang von Software. Kapitel 4 stellte eine ISO/IEC
14143-1 konforme funktionale Softwaremetrik und eruiert ihr Stärken und
Schwächen anhand eines ausgewählten Beispieles.
Softwaremetriken spielen eine große Rolle in der heutigen Softwaretechnik. Mit seiner Aussage
A science is as mature as its measurement tools.
stellte Louis Pasteur (1822-1895) fest, dass jede Wissenschaft soweit verstanden ist wie ihre funktionaler Softwaremetriken. Objektive Kriterien
für Funktionalität, Qualität, Verständlichkeit, Wiederverwendbarkeit und
Komplexität eines Softwareproduktes oder -prozesses zu besitzen bildet die
Voraussetzung für eine geordnete Planung und ein fundierter Beurteilung.
Dieser Auffassung ist auch Tom DeMarco, der sagt:
You can’t control what you can’t measure. [?]
Was genau soll man unter dem Begriff Softwaremetrik verstehen? Eine
Definition von Sommerville besagt:
Eine Softwaremetrik ist jede Art von Messung, die sich auf ein
Softwaresystem, einen Prozess oder die dazugehörige Dokumentation bezieht.
Im IEEE Glossary findet sich folgende die Definition wieder:
236
1 Einleitung
A quantitative measure of the degree to which a system, component, or process possesses a given variable. [ieeeglossary]
Unter dem Begriff Softwaremetrik versteht man ein Verfahren zur Bestimmung eines Merkmals einer Software oder seines Softwareentwicklungsprozesse. Softwaremetriken dienen als Indikatoren für problematische
Softwareentwürfe, Architekturen oder Implementierungen. Sie vermessen
die Software oder ihren Erstellungsprozess um aus der Empirie Aussagen
über z.B. Test- und Wartungsaufwand abzuleiten, Projekte vergleichbar zu
machen oder Implementierungsvorschriften durchzusetzen. Nicht zuletzt werden
Softwaremetriken im Bereich der Projektplanung eingesetzt, um in der
Risikoplanung Kenngrößen, wie z.B. benötigte Mannstunden, abzuschätzen.
Softwaremetriken lassen sich grob in zwei Kategorie einteilen: Prozessmetriken und Produktmetriken. Prozessmetriken quantifizieren wichtige
Kenngrößen eines Entwicklungsprozesses wie den Kommunikationaufwand,
die Fehleranfälligkeit oder den Ressourcenaufwand (Kosten, Zeit oder Mitarbeiter). Zum anderen gibt es die Klasse der Produktmetriken, die Merkmale
eines Softwareprodukts messen. Beispiele solcher Merkmale sind Umfang,
Lesbarkeit, Komplexität oder Qualitäten wie Modularität, Kopplung oder
Wiederverwendbarkeit.
Im Kapitel 2 werden immer noch weit verbreitete klassische Produktmetriken vorgestellt. Die folgenden Kapitel 3 und 4 stellen neue Ansätze der
Prozessmetriken vor.
1.1
Maßtheorie
In der Maßtheorie beschäfigt man sich mit Messtechniken mit deren Hilfe
man ein empirisches Merkmal von Objekten der realen Welt auf ein numerische oder symbolische System abbildet. Gegenstand einer Messtechnik
ist die Untersuchung einer empirischen Relation bezüglich eines Merkmal
von Objekten aus der realen Welt, die wiederum Rückschlüsse auf die reale
Situation zulassen. Als Messtechniken eignen sich somit nur Abbildungen,
die die zu untersuchende empirische Relation respektieren. Damit sich eine
Messtechnik eignet, um ein Analyse durch zuführen, muss sie also ein Homomorphismus bezüglich der empirische Relation sein.
Ziel des Messvorgangs ist es gültige Aussagen über die reale Welt zu
machen, indem die numerischen Resultate analysiert und interpretiert werden. Eine Metrik muss dabei nur die Repräsentationsklausel erfüllen oder
auch validierbar sein, damit solche Rückschlüsse überhaupt zulässig sind und
korrekte Aussagen liefern. Im Folgenden wird Vorgang des formalen Messen
237
in Teilschritte aufgeschlüsselt.
1. Auffinden eines Merkmals von Objekten einer Sort aus der realen Welt
2. Untersuchung der empirischen Relationen zwischen den Objekten
bezüglich dieses Merkmals
3. Auffinden von numerischen Relationen für jede empirische Relation
4. Definition einer Abbildung von Objekten der realen Welt in ein numerisches System
5. Überprüfung auf Konformität der Abbildung bezüglich der empirischen
Relationen und der numerischen Gegenstücke
6. Anwendung der Abbildung auf die Objekten der realen Welt
7. Schlussfolgerung auf Basis der numerischen Resultate auf die reale Situation
8. falls nötig Durchführung von Verbesserungen der realen Situation
1.2
Skalen
In dem obigen Abschnitt wurden Grundlagen für formale und valdierbare
Messtechniken erläutert. In vierten Schritt des formalen Messen wurde jedoch nicht geklärt, welche Klassen numerischen Systemen es gibt und welches
vielleicht anderen vorzuziehen sind. Unter einer Skala wollen wir die bei
einer Metrik verwendete Abbildung zusammen mit ihren empirischen und numerischen Relationen verstehen. Es gibt verschiedenen Klassen von Skalen,
die sich darin unterscheiden wie reich das numerische Zahlensystem ist auf
dem man die Merkmale des empirischen Systems abbilden und wie sehr sie
arithmetische Operationen zulassen aus denen man sinnvolle Resultate erhält. Im folgenden Abschnitt werden fünf Klassen von Skalen vorgestellt, die
jeweils eine Spezialisierung der vorangegangen Klasse darstellen und jeweils
eine präzisiere Beschreibung der realen Welt zulassen. Die 1.2 zeigt schematisch diese Enthaltenseinbeziehung zwischen diese Klassen.
1. nominale Skalen: Diese Klasse lässt nur die Unterteilung des empirische Relationensystem in unterschiedliche Klassen zu. Es existiert
keine Ordnung auf der Menge der Objekte. Bezüglich des zu untersuchenden Merkmals lässt sich nur nur die Gleichheit oder Ungleichheit
feststellen. Zum Beispiel lassen sich Softwareprodukte bezüglich ihres
Anwendungsbereiches nur in Kategorien wie Finanzsoftware, Büroanwendung, Logistiksoftware unterteilen.
238
1 Einleitung
2. ordinale Skalen: Bei dieser Klasse existiert eine totale auf dem Wertebereich des Maß, die eine totale Ordnung der realen Objekten induziert. Wie bei den nominalen Skalen werden hier die realen Objekte
in unterschiedlich Klasse eingeteilen solange diese unter der Metrik erhalten bleiben. Zusätzlich sind hier Kleiner-,Größer- oder Gleichheitsrelationen auf Klassen oder Objekten definiert. Ohne Bedeutung sind
Operationen wie Addition oder Subtraktion. Ein Beispiel für eine ordinale Skala wäre eine Bewertung von Softwaremodulen bezüglich ihrer
Portabilität auf einer Wertebereich von –, -, 0, +, ++.
3. Intervalskalen: Bei diesem Skalentyp handelt es sich um eine Zuordnung auf einen Skalenbereich beim dem Reihenfolgen und Differenzen
erhalten bleiben. Der Nullpunkt ist im Allgemeinen willkürlich festgelegt und bedeutet nicht auf das Nichtvorhanden sein des zu untersuchenden Merkmals hin. Artimetische Operationen wie Addition und
Substraktion der numerischen Wert sind bei Intervalskalen zulässig und
sinnvoll. Die Maßeinhalt Celsius ist ein Beispiel für eine Intervalskala.
Mit ihrer Bestimmung können Temperaturunterscheide gemessen und
verglichen werden. Die Berechung von Temperaturverhältnisse in Celsius sind dagegen von keinem Nutzen.
4. Verhältnisskalen: Metriken vom Verhältnisskalentyp bilden Objekte
auf Null oder echt positive Zahl ab. Sie erhalten Ordnung, Differenzen
und Verhältnisse. Jegliche Art von Arithmetik auf den diesen Skalentyp, wie insbesondere die Division oder die Multiplikation, sind zulässig
und enthalten meist eine sinnvolle Interpretation. Zusätzlich verweist
der Wert 0 auf das Fehlen des Merkmals. Der veranschlagte Preis eines
Softwareprojekt in Euro ist eine solche Verhältnisskala mit deren Hilfe
man Softwareprojekte relative oder auch prozentual vergleichen kann.
5. absolute Skalen: Dieser Skalentyp bildet auf den Bereich der natürlichen Zahlen ab, indem das zu untersuchende Merkmal aufgezählt
wird. Beim absoluten Skalentyp gibt es nur eine Möglichkeit die Anzahl zu bestimmen. Wiederum sind alle arithmetischen Operationen
sinnvoll. Z.b. ist Anzahl der Source Lines of Code eines Softwaremoduls eine absolute Skala für die Anzahl der enthaltenen Zeilen des
Quellkodes (bei eindeutiger Festlegung von LOC, siehe Abschnitt 2.1).
Relative und absolute Häufigkeiten einer absoluten Skala lassen sich
bestimmen und liefern aussagekräftige Resultat.
239
Figure 1: Skalen Klassen
2
2.1
klassische Softwaremetriken
LOC - Lines of Code
Eine der einfachsten Metriken ist Umfangsmetrik LOC (engl. lines of code).
Diese Metrik misst die in einer Software enthaltenen Quellkodezeilen. Es
sind jedoch vielen Fragen bei der Definition von LOC zu klären, was sie
in der Regel untäglich macht Softwareprojekte miteinander zu vergleichen.
Zunächst muss klar sein ob und wie Kommentare oder Leerzeilen gezählt werden. Auch muss die Frage, wie mit Codeexpansion durch Makros umzugehen ist, beantwortet werden. Das größste Problem bei der Definition von
LOC ist wie man mit Zeilen, die aus mehreren programiersprachlich Konstrukten wie Anweisung oder Deklaration bestehen, umgegangen wird; im
einfachsten Fall erhalt jede Zeile ein Gewicht von 1. Aufgrund seiner extrem simplen Messbarkeit ist die LOC Metrik im noch weitverbreitet. Eine
Variante von LOC, genannt NCSS (engl. Non Commentary Source Statements) zählt ohne Berücksichtigung von Makros, Kommentaren oder Deklarationen nur Anzahl in einem Modul enthaltenen Anweisungen und behebt
dabei einige Mehrdeutigkeit des LOC Begriffs. Jedoch ist unklar, ob die LOC
Metrik ihr Ziel erfüllt, nämlich den Umfang einer Software zu messen. Offensichtliche Nachteile von LOC sind, dass es nicht die strukturelle Komplexität
eines Programms berücksichtigt und dass sein Einsatz innerhalb eines Softwareentwickungsprozesses erst in der Implemenierungsphase stattfinden kann.
240
2 klassische Softwaremetriken
Ausserdem sind die Ergebnisse von LOC sehr abhängig von externen Faktor
wie der Wahl der Programmiersprache, Kodierungrichtlinien oder Interpretation des LOC Begriffs, was das folgende Beispiel in 2.1 zeigt.
Figure 2: LOC Berechungen
2.2
zyklomatische Komplexität von McCabe
Im Jahr 1976 entwickelte Thomas McCabe die zyklomatische Komplexität
eines prozeduralen Programms. Diese Softwaremetrik misst die Größe eines
prozeduralen Programms, indem es dem strukturellen Aufbau seiner enthaltenen Kontrollflüsse als Flussgraph modelliert. Die Metrik eignet sich bedingt
241
auch für object-orientiert Software, wenn man die auf der Ebene von Methoden anwendet. Die Grundidee dabei ist, dass mit der Anzahl an verschiedenen Kontrollflüsse in einem Programm bzw. unabhängigen Pfaden seines
KontrollFlussgraphen dessen Komplexität und Wartungsaufwand steigt. Der
Kontrolflussgraph G eines Programms wird dabei definiert als gerichteter
Graphen mit zwei ausgezeichneten Knoten, den Start- und Stopknoten. Aus
dem Stopknoten führen keine Kanten heraus und alle anderen Knoten liegen
auf einem Pfad zwischen Start- und Stopknoten. Jeder Knoten entspricht der
Auswertung einer Anweisung des Programms und jede Kante einen möglichen
Lauf des Kontrollflusses. Die zyklomatisch Kompletität die definiert als
V (G) = e − n + 2p, wobei e die Anzahl der Kanten, n die Anzahl den
Knoten und p die Anzahl der Komponenten des Kontrollflussgraphen bezeichnen. Es lässt sich zeigen, dass wenn die Anzahl der Komponenten p gleich 1 die zyklomatisch Kompletität V (G) gleich π + 1, wobei π die Anzahl
binärer Verzweigungen bezeichnet. Die 2.2 illustriert die Berechnung der zyklomatischen Komplexität anhand der Kontrollflussgraphen von drei kurzen
Programmfragmenten.
Figure 3: Kontrollflussgraphen
Die Klassifikation in 2.2 unterteilt Quelltexte nach ihrer Verständlichkeit
bzw. Fehleranfälligkeit.
242
zyklomatische Komplexität V(G)
Quellkode Charakteristika
≤ 10
verständlich und einfach strukturiert
11 − 20
durchschnittlich verständlich
21 − 49
problematisch und teuer in der Wartung
≥ 50
unverständlich und sehr fehleranfällig
Figure 4: Quellkode Klassifizierung
Es sei anzumerken, dass der bei der Berechnung von V (G) ermittelte
Kontrollflussgraph genutzt werden kann, um eine Menge von Testfällen mit
voller Zweigabdeckung zu erzeugen. Die zyklomatischen Komplexität weist
allerdings eine Anomalie auf. Betracht man ein Programm, welches aus n ineinander verschalten IF -Anweisungen mit jeweils einer Anweisung und einem
leerem Else-Zweig besteht, so läßt sich leicht zeigen, dass V (G) den Wert
n + 1, obwohl das entsprechende Programme für den Leser auch für große n
leicht zu verstehen ist.
2.3
Die Halstead Komplexität
Eine weitere verbreitete Softwaremetrik geht auf eine Arbeit von Martin
Halstead aus dem Jahre 1972 zurück. Die Halstead Komplexität misst die
strukturelle Komplexität des Quellkodes eines Moduls. Halstead Idee ist
dabei, dass der Umfang einer Software mit der Anzahl an Operator und
Operanden korreliert ist. Die Menge der Operatoren bzw. Operanden
ist durch die zugrunde liegende Programiersprache festgelegt. Die Anzahl
verschiedener Operatoren, die der Quellkode enthält sein ν1 . ν2 bezeichnet
die Anzahl verschiedener Operanden. N1 ist die Anzahl angewandter
Vorkommen von Operator und N2 die Anzahl angewandter Vorkommen von
Operanden. Mit ν = ν1 + ν2 bezeichnet Halstead die Größe des Vokabulars
und mit N = N1 + N2 die Länge der Implementierung. Basierten auf diesen
Größen leitet Halstead die folgenden drei Größen ab:
1. Schwierigkeit: D =
ν1
2
∗
N2
ν2
2. Volumen: V = (N1 + N2 ) ∗ log2 (ν1 + ν2 )
3. Aufwand: E = D ∗ V
Die abgeleiten Größen werden wie folgt interpretiert.
• D: misst den Schwierigkeitsgrad das Programm zu verstehen und ist
mit ihr positive korreliert. Nν22 entspricht dem gemittelten Operandenvorkommen.
243
• V: mißt den Umfang der Implementierung
• E: mißt den gesamt Aufwand ein Programm zu verstehen
Zur Messung der Halstead Größen bedarf es eines sprachabhängigen Scanners, welcher pro Modul angewandt wird. Durch Mittelwertsbildung wird so
der mittlere Aufwand oder das mittlere Volumen pro Modul einer Software
bestimmt.
2.4
Objekt-orientierte Metrik von Chidamber and
Kemerer
Chidamber und Kemerer schlugen eine Metrik für objekt-orientiert Software, die die strukturellen Besonderheit und Charakteristika von objektorientierter Software berücksichtigt. Die einzelnen Bestandteile diese Metrik
beziehen sich jeweils auf eine Klasse oder Modul und werden im Folgenden
erläutert:
1. Abhängigkeit zwischen Objekten Das CBO Maß (engl. für Coupling between objects) zählt zu einem gegebenen Modul die Anzahl abhängigen Module. Zwei Module sind genau dann abhängig,
wenn das eine Modul Instanzen oder statische Methoden des anderen verwendet oder umgekehrt. Ein hoheren CBO Index weist auf
schwaches Niveau der Datenkapselung hin, was die Wiederverwendbarkeit schwierig macht.
2. Reaktionsgrad Der Reaktionsgrad einer Klasse ist die maximale Anzahl an Methoden die ausgeführt werden können, wenn ein Objekt
dieser Klasse eine Nachricht erhält. Bei diesem Maß wird angenommen,
dass mit dem Reaktionsgrad einer Klasse seine Komplexität steigt.
3. Gewichtete Methodenanzahl Es existieren zwei Varianten von
diesem Maß, die jeweils gewichtete dir Anzahl der Methoden zählt.
Das erste Maß WMC1 (engl. weighted methods per class 1), welches
jede in einer Klasse enthaltenen Methoden das Gewicht 1 zuordnet und
somit die Anzahl der enthaltenen Methoden misst. Und zum anderen
gibt es das WMC Maß, das alle privaten Methoden einer Klasse vernachlässigt und mit 0 gewichtet. Alle anderen Methoden werden bei
der WMC Bestimmung mit 1 gewichtet.
4. Tiefe des Vererbungsbaums Die Idee dieses Maßes, genannt DIT
(engl. depth of inheritance tree of a class), ist je tiefer der Vererbungsbaum einer Klasse ist umso schwieriger ist das Zusammenspiel zwischen vererbten und redefinierten Methoden zu verstehen. Das DIT
244
Maß einer Klasse ist durch die Länge des längsten Vererbungspfades
seiner Basisklassen bestimmt. Bei Programmiersprachen, die keine
Mehrfachvererbung kennen, ist dies die Anzahl aller Vorfahrenklassen
bis zum Vererbungsende.
5. Anzahl der Kindklassen Beim NOC Maß (engl. number of children)
wird die Anzahl aller direkten Kindklassen aufgezählt. Intuitiv deutet
ein hoher NOC Wert auf ein fehlendes Abstraktionsniveau der zugrunde
liegenden Klasse hin.
6. Kohäsionsmangel Der LCOM (engl. lack of cohesion on methods)
Wert einer Klasse ist die Differenz aus der Anzahl seiner Methodenpaaren, die disjunkten Mengen von Feldern verwenden, und der Anzahl
der Methodenpaaren, die gemeinsam genutzten Felder besitzen. Falls
dieser Wert negativ wird LCOM den 0 angenommen. Ein hoher LCOM
Wert ist ein Indikator dafür, dass die Klasse in mehrere Abstraktionen
enthält und in mehrere Klassen zerteilt werden sollen.
Empirische Untersuchungen haben ergeben, dass alle genannten Untermetriken positiv mit der Fehlerwahrscheinlichkeit eines Moduls oder einer
Klasse positiv korrelliert sind. Ein Ausnahme bildet das NOC Maß, welche
negativ korreliert ist.
2.5
Funktionspunkt Analyse
Allan Albrecht stellte 1979 bei IBM eine Method zur Messung funktionaler
Größe einer Software vor. Albrecht erkannte früh, dass der Umfang einer der
Hauptfaktoren für den Aufwand bei der Entwicklung, Wartung oder bei dem
Betrieb einer Software darstellt. Aus seinen Forschungen nach Möglichkeiten
diesen Aufwand abzuschätzen entstand seine Function Point Analysis Methode.
Albrecht’s Function Point Analysis Methode (kurz FPA) hat als Ziel den
funktionalen Umfang einer Software als eine von seinen funktionalen Benutzeranforderungen abgeleitete positive Größe, Function Points oder F P
genannt, zu bestimmen oder vorherzusagen. Sie misst somit mehr die
Größe des Ausgangsproblems und weniger die Größe einer konkreten Lösung. Die Messung des funktionalen Umfangs einer Software ist wegen ihrer
Unabhängigkeit von der Wahl der eingesetzten Technologien und von Implementierungsentscheidungen ein maßgebliches Werkzeug in der Softwaretechnik. Dieses Prinzip, kleinste funktionale Einheiten eines Softwaresystems
zu identifizeiren und zu zählen, wurde nach Veröffentlichnug von Albrecht’s
FPA vielfach aufgegriffen und weiterentwickelt. Alle daraus resultierenden
245
Konzepte und Methoden oder auch Functional Size Measurement Methods
haben eine etwas unterscheidliche Ausfassung von dem was die funktionallen Bestandteile eine Softwaresystems sind und welchen Einfluss sie auf
die Gesamtgröße haben. Die Funktionseinheiten einer Softwaresystems zu
zählen kann auch in dem Fall, dass die Anforderungen an die Software formal spezifiziert sind, eine sehr schwierige Aufgabe sein. Albrecht’s Function Point Method zählt im Wesentlichen kleinste funktionale Einheiten eines
spezifizierten oder bereit implementierten Softwaresystems. Der erste FPASchritt zählt die sogenannten unangepassten Funktionspunkte UFP (engl.
unadjusted function points). Um diesen Vorgang zu vereinfachen schlägt
Albrecht die Einteilung aller Funktionen in die fünf Kategorien externe Ausgaben, externe Eingaben, externe Anfragen, externe Schnittstellen und interne Dateien vor.
1. Unter Externe Eingaben sind alle Daten zu verstehen, die das System
aus externen Quellen erhält und die eine intern Verarbeitung anstoßen.
2. Externe Ausgaben bestehen aus alle vom System verarbeiten Daten,
die die Softwaregrenze verlassen. Z.b. Daten die auf einen Drucker oder
Bildschirm gesendet werden.
3. Externe Anfragen sind sowohl Eingabeanfragen als auch Ausgabeanfragen, die die internen Daten nicht verändern. Eine Datenbankabfrage
wäre ein Beispiel für eine externe Anfrage.
4. Unter der Kategorie Externe Schnittstellen fallen alle Daten, die
mit externen Systeme geteilt werden. Gemeinsam genutzte Datein,
Programmbiliotheken oder Datenbank sind klassische Beispiel für Externe Schnittstellen.
5. Interne Dateien sind alle systemeigene logische Daten und Dateien.
Eine Konfigurationsdatei oder eine Datei, die Information aller Benutzerprofile enthält, fallen in diese Klasse.
Dabei unterteilt die FPA Methode diese fünf Kategorien weiter nach ihrer
Komplexität in einfach, durchschnittlich und schwierig und ordnet jedem der
resultierenden 15 Unterklassen einen gewichteten Faktor, genannt Function
Count Weighting Factors.
246
einfach mittel schwierig
externe Ausgaben
3
4
6
externe Eingaben
4
5
7
externe Anfragen
3
4
6
externe Schnittstellen
5
7
10
interne Dateien
7
10
15
Figure 5: Function Count Weighting Factors
Die FPA Methode ermittelt ausgehen von der Function Count Weighting
Factor Matrix den unangepassten Funktionspunktwert UFP des Systems,
in dem sie alle funktionalen Einheiten des System in einer der 15 Klassen
einstuft und sie mit durch ihren Function Count Weighting Factors gewichtet
nach der folgenden Vorschrift auszusummiert.
3 P
5
P
UF P =
wij aij , wobei wij der jeweilige Function Count Weighting
i=1 j=1
Factor und ai j die Anzahl der Funktionen der Kategorien i, j bezeichnet.
Die FPA Methode versucht in einem zwei Schritt die UFP Wert zu präsisieren. Das Systems wird weiter hinsichtlichtlich ihrer Zugehörigkeit in eine
technische Kategorie unterteilt. Der Anwender von FPA soll nun die 14 Kategorien nach ihrer Relevanz im System auf einer Skala von 0-5 (irrelevant bis
essentiell) einstufen und kann anschließend den technischen Komplexitäts1
P
faktor TKF des System mit Hilfe der Formel T KF = 0 65 + 0 01 4Fi
1
berechnet. Ein Einstufung mit dem Wert 5 der Kategorie Die 2.5 zeigt eine
Auflistung der Kategorien aus den sich der TKF zusammensetzt.
F1 Reliable back-up and recovery F2 Data communications
F3 Distributed functions
F4 Performance
F5 Heavily used configuration
F6 Online data entry
F7 Operational ease
F8 Online update
F9 Complex interface
F1 0 Complex processing
F1 1 Reusability
F1 2 Installation ease
F1 3 Multiple sites
F1 4 Facilitate change
Figure 6: Kompontenten des technischen Komplexitätsfaktors
Das Resultat der FPA Methode, die Funktionspunkte (FP), ist dann das
Produkt des technischen Komplexitätsfaktors und den unangepassten Funktionspunkten oder kurz F P = U F C × T CF .
247
2.5.1
Resumee
Albrecht’s FPA Methode ist intuitiver und empirischer Ansatz, der nicht explizit auf einer theoretischen Basis oder einem Modell aus der Maßtheorie
aufbaut. Aus diesem Grund ist unklar, was der FP Wert aussagt, und wie
vergleichbar mehrere Softwaresysteme bzgl. FP sind. Zudem beinhaltet der
Bestimmung des FP Wertes eine subjektiven Einfluss, der sich das Endresultat um -35 bis 35 Prozent verändern kann. Zudem haben Kitchenham and
Känsälä ( [KiKä93]) 1991 bei ihren empirischen Erhebungen zu FPA festgestellt, dass die technische Anpassung des UTP Wertes durch den TKF
keine Verbesserung für die resultierende Schätzung der realen FP bringt.
Trotz der genannten Schwierigkeiten setzt, angeregt durch Albrecht’s FPA,
die rege Evolution der FSM Methoden Ende der siebziger Jahren ein. Viele
Methoden griefen das FP Grundprinzip auf ein System aus der funktionalen
Perspektive des Anwender und nicht technischen Sicht des Systementwicklers zu betrachten und daraus den Aufwand zu schätzen, nicht zuletzt weil
die funktionale Perspektive es erlaubt eine frühe Schätzung (bezogen auf den
Lebenszyklus des Systems) zu geben.
2.6
klassische Metriken in einer Anwendung
In diesem Abschnitt soll der Einsatz von Softwaremetriken anhand des OpenSource Project GNU Crypto demonstriert werden. Das GNU Crypto Projekt stellt eine alternative cryptographische Programierschnittstelle zu dem
de-facto Standard JavaSoft’s JCA/JCE dar und ist im Quellkode, der in
Java geschrieben ist, frei verfügbar. Zur Messung wird das von Frank Sauer
entwickelte Plugin Metrics für die Entwicklungplatform Eclipse eingesetzt,
welches eine Reihe von Softwaremetriken wie LOC, McCabe Komplexität
oder Weighted Methods per Class auf der Basis von Java-Quellkode berechnet. Das Metrics Plugin stellt die Messresultate in einem sogenannten Metrics View dar. Die Metrics View Ansicht bestellt aus einer baumartigen
Ansicht dar. Die baumartige Ansicht enthält biszu fünf Ebenen, die die
Messresultate nach Metriken, Gesamtprojekt, Paketen, Klasse bis hin zu den
einzelnen Methoden oder nach Paketen und enthaltenen Typen aufschlüsselt.
Es ist möglich für jede Metrik Ober- und Unterbereichsgrenzen zu definieren,
wodurch die Pfade von Messwert außerhalb des Gültigskeitsbereich in der
Metrics View Ansicht rot markiert werden. Ausserdem kann das Plugin
bei Bereichsverletzung Out of Range Warnungen erzeugen. Dadurch ist es
möglich problematische Stellen im Quellkode schon bei Kodieren zu identifizieren und mit Hilfe eines Doppelklicks in der Metrics View oder Problems
View direkt dort hinzu navigieren.
248
Figure 7: Messresultate des GNU Crypto Quellkodes
Die 2.6 zeigt wie die Metrics View Ansicht die abgeleiteten statistischen Kenngrößen der berechneten Messwerte wie Summe (Total), Mittelwert
(Mean), Standardabweichung (Std.Dev.), Maximum und der Klasse, dem
Packet oder der Method, die den größsten Messwert, auflistet. Das Plugin hilft einen schnell problematische Klassen zu identifieren. Ein solches
Beispiel ist die Klasse SRPServer aus Abbildung 2.6, die fünf Methoden aus
als 50 Kodezeilen enthält und insbesondere die Methode sendProtocolElements, welche aus 107 Zeilen besteht und eine inakzeptabel hohe zyklomatische Komplexität von 63 aufweist.
249
Figure 8: Messresultate des SRPServer.java Quellkodes
Mit Hilfe von Refakturierungsmethoden kann ein Programmierer nun die
problematischen Kodefragmente leicht in kleinere Methoden aufteilen und so
besseren und verständlichen Kode erzeugen, was unteranderem die Erweiterbarkeit, Änderbarkeit und Wartbarkeit signifikant erhöht.
3
ISO 14143 Standard zur Messung funktionaler Größe
Der Standard ISO/IEC 14143-1 wurde 1998 in Kooperation der Standardisierungsorganisationen ISO (engl. International Organisation for Standardization) und IEC (engl. International Electrontechnical Commission) veröffentlicht und definiert fundamentale Konzepte, Methoden und Terminologien
für den Entwurf und Einsatz funktionaler Größenmessung (engl. Functional
Size Measurement, kurz FSM) von Software bzw. ihrer Anwendung in der
Projektplanung, Projektrisikoanalyse, Produktivitätsmessung oder Projektmessung. Der Standard beschreibt keine konkrete Implementation einer
250
3 ISO 14143 Standard zur Messung funktionaler Größe
FSM Methode oder ihrer Details zu ihrem Einsatz, sondern ein Rahmenwerk
oder Metastandard mit man konsist FSM Methoden beschreiben und entwickeln kann. Ziel dieses Rahmenwerks ist es einen einheitlichen Standard
vorzugeben, der bisher fehlte um Methoden hinreichend genau zu vergleichen oder ineinander zu konvertieren. Ein weiteres Ziel des Standards ist
es das Problem zu beseitigen, dass Softwareunternehmen zuvor nur unzureichend in der Lage waren geeignete quantitative Methoden zu finden, um
die Kosten für Entwicklung, Wartung oder Verbesserung ihrer Softwaresysteme abzuschätzen oder die Effektivität und Effizienz ihrer Prozesse zu bewerten und mit anderen Unternehmen zu vergleichen. Dabei spielt die genaue
Bestimmung oder die Prognose der Größe der resultierenden Software eine
zentrale Rolle. In der Vergangenheit wurden auf diesem Gebiet hunderte
Verfahren vorgestellt und eingesetzt, z.b. die SLOC, McCabe oder Halstead
Metriken. Die meisten dieser Verfahren leiden allerdings unter erheblichen
Schwachpunkten. Viele dieser Verfahren setzen den vollständigen Quellkode
des Systems voraus und sind ungeeignet um in einer frühen Phasen des Softwareerstellungprozesses eingesetzt zu werden oder sie lassen sich nicht einheitlich während des gesamten Lebenszyklus des Systems anwenden. Häufig
sind die vorgeschlagen Verfahren auch nicht hinreichend verstanden und es
ist unklar was sie genau messen und können deshalb nicht sinnvoll eingesetzt
werden. FSM Methoden sind dagegen so konzeptiert, dass sie keine konkrete
Implementation messen, sondern sie spezifizieren die Größe eines System anhand der funktionalen Anforderungen des System, und verweiden deshalb die
genannten Schwachstellen. Seit Albrecht’s Veröffentlichung seiner Funktionspunkt Analyse griefen viele seine Ideen auf und entwickelten sie weiter, was
zu Inkonsistenzen der einzelnen Methoden führte und die Standartisierung
einer FSM Methode erschwerte. Der ISO/IEC Standard legt die fundamentalen Konzepte von FSM Methoden fest und versucht eine konsistente Behandlung und Weiterentwicklung der FSM Methoden zu propagieren und ist
in sechs Teile aufgeschlüsselt.
1. Definition der Konzepte
2. Conformity Assessment of Software sizing methods to ISO/IEC 141431:1998
3. Verification einer FSM Methode
4. FSM Referenzmodel
5. Bestimmung von funktionalen Domänen für den Einsatz von FSM
251
6. Anleitung zur Benutzung der ISO/IEC 14143 Reihe und verwandten
internationalen Standards
Im folgenden werden die zentralen Konzepte und Definitionen des
[ISO14143] Standards zitiert:
Base Functional Component (BFC) Base Functional
Component (BFC) an elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes
BFC Type a defined category of BFCs
boundary a conceptual interface between the software under
study and its users
FSM Method a specific implementation of FSM defined by
a set of rules, which conforms to the mandatory features of this
part of ISO/IEC 14143
Functional Domain a class of software based on the characteristics of Functional User Requirements which are pertinent
to FSM
Functional Size a size of the software derived by quantifying
the Functional User Requirements
Functional Size Measurement (FSM) the process of measuring Functional Size
Functional User Requirements - FUR a sub-set of the
user requirements. The Functional User Requirements represent
the user practices and procedures that the software must perform
to fulfil the users? needs. They exclude Quality Requirements
and any Technical Requirements
User any person that specifies Functional User Requirements
and/or any person or thing that communicates or interacts with
the software at any time NOTE - Examples of ’thing’ include,
but are not limited to, software applications, animals, sensors, or
other hardware.
252
4 COSMIC-FFP
Der Metastandard spezifiert weiter die folgenden Charakteristika und Anforderung, die eine Metrik aufweisen muss um Komformität mit ISO/IEC
14143 zu erreichen, dabei ist die Bedeutung des Wortes soll als eine strike
Anforderung an die FSM Methode zu verstehen.
Die Methode arbeitet mit einer Repräsentation aller systemeigenen Anforderung (FURs) aus Sicht des Benutzers und kann ab dem Zeitpunkt
ihrer Erstellung eingesetzt werden. Desweitern sollte die Methode BFC
Typen definieren (und falls vorhanden deren Relationen untereinander),
den zumessenden funktionalen Umfang auf Basis dieser Typen ableiten und
Regeln und Methoden beinhalten mit denen man die einzelnen BFCs anhand der vorliegenden FURs identifizieren kann und eindeutigen einem BFC
Typ zuordnen kann. Die BFCs sollen keinen Bezug auf technische Systemanforderungen oder Qualitätsanforderungen enthalten. Zudem soll die
Methode definieren wie jeder BFC ein numerischer Wert unter Berückigsichtigung seines BFC Typs zugewiesen wird. Diese Regeln sollen unabhängig
von Methoden und dem Aufwand zur Entwicklung und Wartung des Systems
sein. Informationen, die für ihre Anwendung benötigt werden, sollen die FSM
Methode spezifieren und Richtlinien festlegen, wie ihre Anwendung zu dokumentieren ist. Eine FSM Methode soll ihren funktionalen Einsatzbereich festlegen, d.h. für welche Systeme bzw. Anwendungsbereiche sie konzepiert ist.
Sie solltest auch soweit wie möglich unabhängig sein der Wahl der eingesetzten Technologien und Entwicklungsmethoden. Soweit möglich soll festlegt
sein zu welchem Grad die Methode kompatibel zu anderen FSM Methoden ist
und wie potentielle Konvertierungen durchzuführen sind. Die FSM Method
soll aus Konvention einen eindeutigen Namen besitzen und falls vorhanden
unterschiedliche Versionen durch eine entsprechende Versionsnummer kenntlich machen.
4
COSMIC-FFP
Das Common Software Measurement International Consortium initiierte
1997 das COSMIC FFP Projekt mit dem Ziel neue Methoden zu entwerfen mit deren Hilfe man den Umfang und die Kosten von Software genauer
schätzen und bestimmen kann. Außerdem sollte COSMIC FFP einen internationalen Standard entwickeln, testen und bis zur Marktreife bringen. Das
Konsortium traff gleich zu Beginn einige Entwurfsentwurfsentscheidungen.
Z.b. sollten die Methoden insbesondere Informationssysteme, Realzeitsysteme oder Mischformen dieser beiden unterstützen. Sie sollten aber auch
in einer frühst möglichen Phase eines Softwareentwicklungsprozesses einsetzbar und unabhängig von Implementierungsaspekten sein. Das dem Projekt
253
entstand die gleichnamige COSMIC-FFP (COSMIC Full Function Points)
Methode, die mit Unterstützung der ISO/IEC JTC1 SC7 Gruppe im Dezember 2002 als als ISO/IET 14143-1 konforme FSM Methode standardisierte
wurde. Die COSMIC FFP Methode unterliegt bis heute einem ständigen
Überarbeitungsprozess, der zum heutigen Stand die Version 2.2 der Methode
hervorbrachte (siehe [cosmiconhome]).
4.1
COSMIC FFP-2.2
Im diesem Abschnitt wird eine grober Überblick über die Arbeitweise der
COSMIC FFP Methode gegeben. Zur Anwendung der Methode reicht eine
vollständige Liste aller funktionale Benutzeranforderungen (FUR Liste). Die
Methode ist in zwei Phasen gegliedert. In der Abbildungsphase oder Unifikationsphase werden die FURs des zuvermessenden Systems auf das in Abschnitt 4.2 erläuterte generische COSMIC Softwaremodell abgebildet. Dabei
erhält man an das COSMIC Softwaremodell angepasste FURs, die wiederum
in der Messphase als Eingabe benötigt werden. In der Messphase werden auf
diesem Model Regeln angewandt mit deren Hilfe man die funktionale Größe
des Systems herleitet. Die FURs der Software werden in der ersten Phase
zerlegt in funktionale Prozesse, die wiederum, falls sie zu grob granular sind,
in einzelne funktionale Unterprozesse zerteilt werden. Im COSMIC Model
führen diese Prozesse eine Folgen von Datenbewegungen oder Datenmanipulation aus. Auf Basis der einzelnen Prozesse und deren Unterprozessen
bestimmt die COSMIC FFP Methode vereinfacht gesagt eine Zählung aller
enthaltenen Datenbewegungen (Entries und Exits) und der Datenmanipulation (Reads und Writes) durch und bewertet jede dieser im Modell atomaren
Operationen mit dem Wert 1 und der Einheit Cfsu (COSMIC functional size
unit), um so den FFP Wert des Systems in Cfsu zu ermitteln.
4.2
COSMIC-FFP Software Kontextmodell
Dem COSMIC-FFP Software Kontextmodell verwendet zwei grundlegende
Prinzipien, die im Folgenden aus dem COSMIC Measurement Manual zitiert
werden [Cosmic Measurement Manual]
General Principle 1: The software to be mapped and measured is
fed by input and produces useful output, or a useful outcome, to
users.
General Principle 2: The software to be mapped and measured
manipulates pieces of information designated as data groups
which consist of data attributes.
254
4 COSMIC-FFP
Im COSMIC-FFP Software Kontextmodell ist Software ist umgrenzt von
Hardware. Zum einen ist sie in eine sogenannter Frontend -Grenze zum menschlichen Benutzer durch Ein- und Ausgabehardware wie Tastatur, Maus,
Bildschirm etc. abgeschirmt und zum anderen begrenzen sie persistenten Speicher Medien wie Festplatten, RAMs oder ROMs an der Backend -Grenze. In
Frontend -Richtung erlauben es Entries und Exits die funktionale Datenströme über die Softwaregrenze zum Benutzer. Die entsprechende Datenströme an der Backend -Grenze heissen Reads and Writes.
Figure 9: generisches COSMIC Softwaremodell
4.3
COSMIC-FFP Fallstudie
In dem Abschnitt wird anhand einer Fallstudien eines eingebetteten Systems die Vorgehensweise COSMIC-FFP Methode demonstriert und den Umfang des Softwaresystem in Cfsu bestimmen. Das zugrundeliegende eingebetteten System besteht aus einer Software für einen Controller-Chip, der
in einem Pkw einen festen Abstand zu einem vorausfahrenden Fahrzeug automatisch halten soll. Das zudimensonierende System besteht aus einem
menschlichen PKW-Fahrers, den Sensoren, dem Controller und Akteuren wie
die Bremsen und die Motorsteuerung. Die Sensoren vermessen die Umwelt
nach Parametern wie dem aktuellen Abstand zum Vordermann, die aktuelle
Geschwindigkeit und die Ausfeuchtigkeit und speichern diese Daten für eine
gewisse Zeit. Der Controller kann jederzeit diese Daten der Sensoren und
255
Akteure lesen und soll in dem Fall, dass der Fahrer das System aktiviert
hat, entscheiden, ob der die Akteuren einsetzen soll, um einen bestimmten
Abstand wiederherzustellen.
Formal ergeben sich somit die folgenden funktionalen Benutzeranforderungen:
1. FUR 1 Das System soll durch Bremsen den Abstand zum vorderen
PKW verringen, wenn dieser kleiner ist als der Standardabstand.
2. FUR 2 Das System soll durch Steuerung des Motors den PKW beschleunigen, wenn der Abstand zum vorderen PKW größer ist als der Standardabstand.
3. FUR 3 Deaktiviert der Fahrer das System oder betätigt er die Bremsen
oder das Gaspedal, soll sich das System deaktivieren und die Steuerung
der Akteure enden.
Voraussetzung für FUR 1 und FUR 2 ist zusätzlich, dass das System
aktiviert ist und der Benutzer seit längerem keinen Akteur gesteuert hat.
Der Controller muss also auf die folgenden Simuli des Fahrers reagieren:
1. SYSTEM AKTIVIERUNG
2. SYSTEM DEAKTIVIERUNG
Der Controller muss also auf die folgenden Simuli der Sensoren reagieren:
1. ABSTANDSÄNDERUNG
2. GESCHWINDKEITSÄNDERUNG
3. FEUCHTIGKEITSÄNDERUNG
Der Acteure müssen auf die folgenden Simuli des Benutzer bzw. des
Controller reagieren:
1. BREMSEN
2. BESCHLEUNIGEN
3. INAKTIVITÄT
Da nun alle Benutzeranforderungen vorliegen, können wir die von COSMIC FFP anwenden. Die folgende 4.3 zeigt das System mit seinen Komponenten und seiner Umgebung und gliedert das System in zwei Softwarekomponenten, die innerhalb sich das System befindet: Controller Komponente
256
4 COSMIC-FFP
und Steuerungskomponente. Die 4.3 identifiziert auch gleichzeitig alle Systemgrenzen, die aus der Grenze zum Benutzer und der Grenze zu der Hardware der Sensoren bestehen. Damit wäre der erste Teilschritt der Abbildungsphase von COSMIC FPP abgeschlossen.
Figure 10: Kontrollflussgraphen
Nun müssen wir noch die funktionalen Prozesse identifieren. Da eine
vollständige Schlüsselung aller involvierten funktionalen Prozesse den Rahmen dieser Seminararbeit übersteigen würde, wird hier nur exemplarisch der
funktionale Prozess der Abstandsänderung analysiert und gemessen.
257
Figure 11: Funktionaler Prozess - Abstandsänderung
Die 4.3 zeigt, dass der Prozess der Abstandsänderung aus drei Datenbewegungen (2× Entries und 1 Exit) und einer Datenmanipulation (Read)
besteht. Somit beinhaltet dieser Prozess einen Umfang von 4Cf su. Weil
die Systemgesamtgröße sich aus der Summe aller Größen der funktionale
Prozesse zusammensetzt, wollen wir im folgenden eine Systemgröße von 25
Cfsu annehmen.
Aus den Ergebnissen (vergl. 4.3), die von der COSMIC Gruppe bei
ihren [COSMIC Feldversuchsreihe] gewonnen hat, werden wir nun auf Basis
der Systemgröße von 55 Cfsu der Aufwand für die Entwicklung des Systems
abschätzen. Dabei sei eine Mannstundenzahl von 120 pro Monate und eine
Teamstärke von 5 Personen angenommen.
258
References
Mannstunden pro Cfsu Mannmonate pro Cfsu Mannstunden
26 96
0 224
1482
29 5
0 246
1622
20 7
0 173
1139
Median
2tes Quartile
3tes Quartile
Figure 12: Produktivitätszahlen aus den COSMIC Feldversuchen
Dauer
mittlere
langsamste
schnellste
Stunden
Monate
296 6
2 46 = (1482/5)/120
324 4
2 70 = (1622/5)/120
227 7
1 90 = (1139/5)/120
Figure 13: Systementwicklungsdauer für das Team in Mannstunden bzw.
Monaten
Die mit Hilfe von COSMIC FFP gefundenen Resultate lassen also eine
relativ präzise Eingrenzung der Projektdauer zwischen 1 9 und 2 7 Monaten
zu.
5
Literaturverzeichnis
References
[KiKä93]
Kitchenham, B.A. and Känsälä K., Inter-item correlations amoung function points, Proceedings of the IEEE
Software Metrics Symposium, Baltimore, MD, IEEE
Computer Society Press,pp. 11-15, 1993
[CiKe94]
S.R. Chidamber and C.F. Kemerer, A Metrics Suite
for Object Oriented Design, IEEE Transactions on
Software Engineering, vol.20, no. 6, 1994, pp. 476-493.
[cosmiconhome]
COSMIC Homepage,
Stand vom 26.10.2005
http://www.cosmicon.com,
[Cosmic Measurement Manual] A. Abran, J.M. Deshairnes, S. Oligny, S. StPierre, C. Symons (2003), Measurement Manual COSMIC Full Function Points 2.2, The COSMIC Implementation Guide for ISO/IEC 19761
259
[COSMIC Feldversuchsreihe] Abran, Symons, Oligny (2001) An Overview of
COSMIC-FFP Field Trial Results, Proceedings 12th
European Software Control and Metrics conference,
London
[Fent97]
N.E. Fenton and S.L. Pfleeger, Software Metrics: A
Rigorous and Practical Approach second edition, PWS
Publishing Co., 1997
[ISO14143]
Implementation Note for IEEE Adoption of ISO/IEC
14143-1:1998
[ISOvoc]
International Vocabulary of Basic and General Terms
in Metrology, International Organization for Standardization, Switzerland, 2nd edition, 1993, ISBN 92-6701075-1
[Bassman]
Mitchell J. Bassman, Frank McGarry, and Rose Pajerski, Software Measurement Guidebook, Software Engineering Laboratory Series, Rev. 1, pp. 21-46, 1995.
[ieeeglossary]
IEEE Standard Glossary
260
Objektorientierte Entwürfe
Empirisches Ergebnis
Na Bai
Keywords: BAI,Objektorientierte Entwürfe,Entwurf
Abstract
Im Rahmen dieser Ausarbeitung führen zuerst die wesentlichen Begriffe der Objektorientierung ein und zeigt ihre Darstellung in der Unified Modeling Language (UML). Dann weiter beschäftigt sich mit verschiedenen Aspekten des objektorientierten Entwurfs (object-oriented
design, OOD). Es wird definiert, was Entwurf ist und welche Arten
von Entwurf es gibt. Am Ende wird die Frage, was eigentlich ein guter
Entwurf ist, aus verschiedenen Perspektiven beleuchtet. Dazu werden
einige Beispiele vorgestellt. Dann kann man gut verstehen. Schließlich
wird eine Zusammenfassung des Beispiels gegeben.
1
Grundlagen
1.1
Objektorientierung
Die Begriffe in der Objektorientierung werden häufig unterschiedlich
definiert, oder es werden für dasselbe Konzept unterschiedliche Begriffe verwendet. [3] Daher werden die Definitionen der zentralen Begriffe angegeben,
wie sie in dieser Arbeit verwendet werden. Die verwendeten Definitionen
stützen sich vor allem auf die Begriffsbildung im Zusammenhang mit UML.
Drei Eigenschaften zeichnen die objektorientierte Sichtweise aus:
jekte, Klassen und Vererbung. [2]
Ob-
• Objekt
Die zentrale Rolle spielt der Begriff des Objekts. Ein Objekt besteht
aus Datenfeldern, den so genannten Attributen, und aus Funktionen
auf diesen Daten, den so genannten Methoden. Methoden dienen zur
Reaktion auf Nachrichten, die ein Objekt versteht. Methoden können z.
B. den Zustand des Objekts (die Werte seiner Attribute) verändern oder
neue Nachrichten verschicken. Die Schnittstelle einer Methode wird als
Operation bezeichnet. Eine Methode ist also die Implementierung einer
Operation.
• Klasse
Die Objekte eines Systems werden nicht individuell beschrieben, sondern anhand ihrer Gemeinsamkeiten in Klassen zusammengefasst. Eine
Klasse definiert die Attribute und Methoden ihrer Objekte. Die Klasse
dient als Schablone zur Instantiierung von Objekten. Bei der Instantiierung müssen nur die Werte für die Attribute angegeben werden, die
Methoden übernimmt das Objekt von seiner Klasse.
Abbildung 1. zeigt die UML-Darstellung einer Klasse und eines Objekts
dieser Klasse. Der Name des Objekts wird zur besseren Unterscheidung
unterstrichen.
Figure 1: UML Darstellung von Objekt und Klasse
Kommentare werden in UML durch einen Kasten mit Eselsohr
dargestellt, der mit dem Modellelement, auf das sich der Kommentar
bezieht, durch eine gestrichelte Linie verbunden ist.
• Vererbung
Vererbung ist eine Beziehung zwischen Klassen.
264
Eine Klasse kann
1 Grundlagen
sämtliche Eigenschaften (Attribute und Methoden) einer anderen
Klasse erben, d.h. als Kopie übernehmen. Es dürfen außerdem weitere
Eigenschaften hinzugefügt werden (Erweiterung) und geerbte Methoden modifiziert werden (Redefinition). Bei Einfachvererbung erbt eine
Klasse von genau einer anderen Klasse, bei Mehrfachvererbung von
mehreren Klassen.Die vererbende Klasse heißt Oberklasse, die erbende
Unterklasse.
Bei getypten objektorientierten Programmiersprachen wird die
Vererbungs-relation auf die korrespondierenden Typen übertragen:
Eine erbende Klasse definiert einen Subtyp des durch die vererbende
Klasse definierten Typs. Dadurch entsteht eine zur Vererbungsstruktur
der Klassen isomorphe Typstruktur.
In UML wird die Vererbung durch einen Pfeil mit einer dreieckigen Spitze angezeigt, der von der Unterklasse zur Oberklasse geht.
Geerbte Eigenschaften werden in der Darstellung der Unterklasse nicht
wiederholt.
Figure 2: Vererbung
Vererbung ist ein mächtiges Konzept; durch sie kann viel redundante
Implementierung eingespart werden. Durch Erben kann aber die
Kapselung durchbrochen werden, weil eine Unterklasse Zugriff auf die
Implementierung der Oberklasse erhält. Außerdem ist die Unterklasse
durch das Erben stark an ihre Oberklasse gekoppelt: Jede Änderung
der Oberklasse betrifft auch die Unterklasse.
1.2
1.2.1
Entwurf
Definition
Der Begriff Entwurf (oder Design) hat zwei verschiedene Bedeutungen. Zum
einen bezeichnet er die Gestaltung oder Formgebung eines Gegenstands; bei
265
Software entspricht das vor allem der Gestaltung der Benutzungsoberfläche
(user interface design). Diese Tätigkeit ist Teil der Spezifikationsphase. [6]
Die Abbildung 3.
Entwicklung.
zeigt die Einbettung des Entwurfs in die Software-
Figure 3: Einbettung des Entwurfs in die Software-Entwicklung
Der Entwurf transformiert die Anforderungsspezifikation in eine Entwurfsbeschreibung, die in der Implementierungsphase in Code für ein
ausführbares Programm umgesetzt wird, der danach getestet und gewartet
wird.
Die Entwurfsbeschreibung ist ein wichtiges Dokument für alle anderen
nachfolgenden Phasen. In der Implementierungsphase dient der Entwurf als
Vorgabe, in der Wartung wird er für das Verstehen der Implementierung
benötigt. Innerhalb des Entwurfs können die Aktivitäten Architekturentwurf
und Komponentenentwurf unterschieden werden.
1.2.2
Entwurfsprozess
Abbildung 4. zeigt den Entwurfsprozess. Die Anforderungsspezifikation ist
nicht das Einzige, was den Entwurfsprozess steuert. Hinzu kommen noch
Entwurfseinschränkungen und die Entscheidungen des Entwerfers, die durch
sein Wissen und seine Erfahrung bestimmt sind. Auch die vorhandene Infrastruktur hat Einfluss auf den Entwurfsprozess: Beispiels-weise spiegelt
266
1 Grundlagen
die Struktur des Entwurfs oft die Struktur der entwickelnden Organisation
wieder.
Figure 4: Entwurfsprozess
Der Entwurfsprozess besteht aus drei Phasen (Divergenz, Transformation
und Konvergenz)
• Divergenz (Analyse):
Problemanalyse, Suchraum definieren.
Das Problem wird analysiert und in seine Bestandteile zerlegt.
Anschließend wird ein Suchraum für die möglichen Lösungen aufgespannt. Dies geschieht in der Regel implizit im Kopf des Entwerfers.
Der Suchraum kann aber auch explizit dargestellt werden. Er enthält
die Menge aller Entwurfsmöglichkeiten zu einer Menge gegebener
Anforderungen. Die Dimensionen des Entwurfsraums reflektieren
alternative Anforderungen, Entwurfsentscheidungen (z. B. bestimmte
Architektursmuster) und Bewertungskriterien (z.B. hinsichtlich
Funktion oder Leistung), sie sind in der Regel nicht voneinander
unabhängig. Ein konkreter Entwurf wird durch einen Punkt im
Entwurfsraum repräsentiert.
• Transformation (Synthese):
Generieren von Lösungsalternativen innerhalb des Suchraums.
Innerhalb des in der ersten Phase generierten Suchraums wird nach
Lösungsmöglichkeiten gesucht, die den Anforderungen entsprechen.
Im Entwurfsraum werden die Entwurfsmöglichkeiten in der Regel
nur die sinnvollen Alternativen durch Einordnung auf den einzelnen
267
Dimensionen positioniert.
Indem bisher unbesetzte Bereiche im
Entwurfsraum betrachtet werden, können häufig weitere Alternativen
gefunden werden, die bisher übersehen wurden. Untersucht man
die Korrelationen zwischen den Dimensionen, insbesondere zwischen
Entwurfsentscheidungen und Bewertungen kann die Zahl der sinnvollen
Alternativen schnell eingeschränkt werden, was die Suche beschleunigt.
• Konvergenz (Evaluation):
Bewertung der Lösungsalternativen und Auswahl einer Lösung.
Die Lösungsalternativen der vorhergehenden Phase werden bewertet, und die Lösung mit der besten Bewertung wird ausgewählt.
Durch Einsatz von Checklisten kann bei der Bewertung sichergestellt
werden, dass alle erforderlichen Kriterien erfüllt sind. Die Bewertung
der Alternativen kann auch auf quantitativer Basis durchgeführt
werden, z.B. durch Vergabe von Nutzwerten für Bewertungskriterien
(Nutzwertanalyse). Bei einer Nutzwertanalyse ist also sicherzustellen,
dass alle relevanten Aspekte berücksichtigt und Aspekte korrekt
gewichtet sind, um keine irreführenden Resultate zu erhalten.
1.3
Klassifikationen des Entwurfs
In diesem Abschnitt werden verschiedene Aspekte betrachtet, nach denen
sich der Entwurf klassifizieren lässt: Strategie, Aktivität, Abstraktionsebene
und Struktur.
1.3.1
Strategien
Die Strategie bestimmt, auf welche Weise der Entwurf angegangen wird. Hier
wird die historische Entwicklung hin zur objektorientierten Strategie grob
chronologisch dargestellt.
Kein Entwurf/Impliziter Entwurf Zu Anfang wurden nur kleine Programme in Maschinencode oder Assembler geschrieben. Der Entwurf, sofern
vorhanden, war im Wesentlichen das Programm in einem Pseudocode, der
einer höheren Programmiersprache entsprach. Der Bedarf für einen expliziten
Entwurf auf einer höheren Abstraktionsebene war nicht vorhanden oder nicht
klar. Im Zusammenhang mit der Softwarekrise wurde deutlich, dass ein expliziter Entwurf vorteilhaft ist, wenn komplexere Programme erstellt werden.
268
1 Grundlagen
Strukturierter Entwurf Die Aufteilung des Systems wird vorgenommen anhand von Funktionen (funktionsorientierter Entwurf). Die Granularität des
Entwurfs ist die Prozedur. Datenstrukturen dienen zur Modellierung der
Daten. Eingeführt wurden auch die Ideen der Abstraktion, der Hierarchie
und der Schichten.
Modulorientierter/Objektbasierter Entwurf Das System wird in Module
aufteilt. Unter einem Modul verstand man ursprünglich (beim strukturierten Entwurf) eine Prozedur. Beim modulorientierten Entwurf fasst man,
beeinflusst durch das Geheimnisprinzip und die Theorie der abstrakten Datentypen, Prozeduren und Datenstrukturen zu größeren Einheiten (Modulen)
zusammen. Module, die Datenstrukturen mit den notwendigen Funktionen
auf diesen Datenstrukturen zusammenfassen und kapseln, werden auch als
Objekte bezeichnet; man spricht dann von objektbasiertem Entwurf.
Der objektorientierte Entwurf Der objektorientierte Entwurf nimmt zum
objektbasierten Entwurf noch das Konzept von Vererbung und den damit
zusammenhängenden Polymorphismus hinzu. Damit kann der objektorientierte Entwurf als eine Weiterentwicklung der bisher verfolgten Entwurfsstrategien angesehen werden. Allerdings scheint dennoch ein Umdenken
beim Entwerfen erforderlich zu sein, weshalb auch häufig von einem Paradigmenwechsel die Rede ist.
1.3.2
Aktivitäten
Wie bereits in Abbildung 3. gezeigt können in der Entwurfsphase zwei verschiedene Aktivitäten unterschieden werden: Architekturentwurf und Komponentenentwurf.
Der Architekturentwurf Der Architekturentwurf entwickelt die grobe
Struktur der Lösung, die Architektur. Die wesentlichen Komponenten sind
dabei in der Regel der funktionale Kern, die Benutzungsoberfläche und die
Datenhaltung. Außerdem wird die Verteilung der Komponenten auf Rechnerknoten festgelegt. Das Vorgehen beim Architekturentwurf ist wie folgt: Das
System wird zunächst hierarchisch in Subsysteme zerlegt, die verschiedene
Aufgaben innerhalb des Systems wahrnehmen. Diese Subsysteme werden
verfeinert, bis man zu den Atomen des Architekturentwurfs, den Komponenten, gelangt. Die Beziehungen zwischen den Komponenten, die Konnektoren,
werden identifiziert. Dokumentiert werden schließlich die Subsysteme, die
Komponenten, die Konnektoren und ihre Interaktion zur Laufzeit.
269
Komponentenentwurf Der Komponentenentwurf legt zunächst die
Schnittstellen der Komponenten nach außen fest.
Außerdem werden
wichtige Details für die Implementierung bestimmt, vor allem die zu
verwendenden Algorithmen und Datenstrukturen (Feinentwurf). In der
Praxis entstehen Architektur- und Komponentenentwurf eher parallel als
sequentiell, da beim Komponentenentwurf häufig Fehler oder Schwächen im
Architekturentwurf identifiziert werden; insbesondere müssen häufig andere
Komponenten angepasst werden, mit denen die Komponente interagieren
soll.
1.3.3
Abstraktionsebenen
Anhand des Abstraktionsgrads des Entwurfs kann zwischen logischem und
physischem Entwurf unterscheiden werden.
Der logische Entwurf Der logische Entwurf abstrahiert vom konkreten
Kontext der geplanten Implementierung, z. B. der Plattform (Rechner, Betriebssystem, Netzwerke) und anderen Systemen, mit denen das System interagieren soll (z. B. Datenbank, Middleware). Auf dieseWeise entsteht ein
implementierungsneutraler Entwurf, der in dieser Form nicht direkt implementierbar ist.
Physischer Entwurf Die Brücke vom logischen Entwurf zur Implementierung schlägt der physische Entwurf. Die im logischen Entwurf offen gelassenen Realisierungsentscheidungen werden auf der Basis von Anforderungen durch Kunden und Management, Kostenaspekten ( z. B.
Anschaffungs- und Betriebskosten, Einarbeitungszeit der Entwickler und Benutzer ) und Effizienzüberlegungen ( Laufzeit und Speicherbedarf ) gefällt.
Der Vorteil der Trennung zwischen logischem und physischem Entwurf ist,
dass sich der Entwerfer zunächst keine Gedanken um Implementierungsprobleme und Effizienz machen muss, sondern sich auf die Aufteilung der Funktionalität auf Komponenten konzentrieren kann.
1.3.4
Strukturen
Beim objektorientierten Entwurf kann zwischen statischer und dynamischer
Struktur unterschieden werden. Die statische Struktur beschreibt den Aufbau des Programms zur Übersetzungszeit, während die dynamische Struktur
den Aufbau des Programms zur Laufzeit beschreibt.
270
1 Grundlagen
Statische Struktur Die statische Struktur besteht aus Klassen, Interfaces
und Paketen sowie ihren Beziehungen untereinander. Zu jeder Klasse und
zu jedem Interface werden Attribute und Operationen angegeben. Zwischen
Klassen und Interfaces können verschiedene Beziehungen bestehen: Es
lassen sich Benutzungsbeziehung,Vererbungsbeziehung, Realisierung und
Assoziation (mit ihren Spezialfällen Aggregation und Komposition) unterscheiden. Die Pakete dienen vor allem der hierarchischen Strukturierung der
Klassen und Interfaces.
Die statische Struktur wird in UML vor allem mit Klassendiagrammen beschrieben. Bei einer objektorientierten Implementierung stimmt die
Codestruktur in hohem Maße mit der statischen Struktur überein, da der
objektorientierte Code ebenfalls klassenorientiert ist.
Dynamische Struktur Die dynamische Struktur entsteht beim Ablauf des
Programms. Sie wird vor allem durch die vorhandenen Objekte geprägt, die
Instanzen der Klassen aus der statischen Struktur sind. Die Objekte haben
Beziehungen, schicken einander Nachrichten, ändern ihren Zustand, erzeugen
neue Objekte oder zerstören vorhandene. Die Verteilung der Objekte auf
unterschiedliche Rechnerknoten spielt für die dynamische Struktur ebenfalls
eine Rolle. Jeder Zustand des Systems während der Ausführung ist eine
Ausprägung der statischen Struktur.
Im Gegensatz zur statischen Struktur ist die dynamische Struktur dem Code
nur sehr schwer zu entnehmen. Zum einen besteht sie aus einer Vielzahl von
Objekten, die untereinander in den unterschiedlichsten Beziehungen stehen.
Das Objekt-Netzwerk ist sehr komplex und verändert sich laufend über die
Zeit, so dass es nur in Ausschnitten verstanden werden kann. Zum anderen
ist die Funktion über den Code verstreut.
Ursache für die Delokalisierung ist, dass die Lösung datenorientiert erstellt wird. Dies ist sinnvoll, um eine bessere Abstraktion (im Sinne
abstrakter Datentypen) zu erreichen. Durch die Fokussierung auf die Daten
wird aber die Funktion in kleine Teile zerlegt, die sich den jeweiligen Daten
zuordnen lassen. Die Verteilung der Funktion wird durch Vererbung noch
verstärkt, weil man die Methoden zu den Operationen einer Klasse nicht
an einem Ort findet, sondern sich diese aus der gesamten Vererbungshierarchie zusammensuchen muss. Dynamisches Binden erschwert zusätzlich
eine statische Analyse des Codes, da oft nicht klar ist, welche Methode
tatsächlich aufgerufen wird.
271
Gerade weil die dynamische Struktur im Code schlecht dokumentiert
ist, muss sie im Entwurf hinreichend beschrieben werden, denn sie wird
später zum Verständnis des Codes benötigt werden. Die Dokumentation
kann z. B. in Form von Szenarien mit einigen Objekten und Aufrufsequenzen ihrer Methoden erfolgen. In UML dienen zur Beschreibung der
dynamischen Struktur vor allem Objektdiagramme, Sequenzdiagramme,
Kollaborationsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme.
1.4
Entwurfsmuster
Ein Entwurfsmuster (Design Pattern) [5]beschreibt eine in der Praxis
bewährte Lösung für ein Entwurfsproblem.
Das definieren MikroArchitekturen, d. h. kleinere Einheiten innerhalb einer Architektur1 . Sie
bieten abstrakte Lösungen für das Zusammenspiel weniger Komponenten an.
Häufig geht es um die Entkopplung einzelner Komponenten, um eine bessere
Änderbarkeit zu erreichen.
2
Entwurfsqualität
2.1
Perspektiven der Entwurfsqualität
Entwurfsqualität ist durch verschiedene Perspektiven geprägt:
1. Zeitliche Perspektive: kurz- oder langfristig
2. Interessengruppe: Kunde, Anwender, Entwickler, Projektmanager oder
Projekteigentümer
3. Qualitätssicht: transzendent, produktbezogen, benutzerbezogen, herstellungsbezogen oder kostenbezogen
Es ist praktisch nicht möglich, für jede dieser Perspektiven alle Möglichkeiten
in einem einzigen allgemeinen Modell zusammenzubringen.
2.2
Entwurfsregeln
Um die gewünschten Eigenschaften des Entwurfs in hohem Maße zu erreichen, wurden Unmengen von Ratschlägen publiziert: Methoden, Prinzipien,
Heuristiken, Entwurfsmuster und vieles andere mehr. In diesem Abschnitt
1
Defn: Die Architektur definiert also eine Struktur, die aus Komponenten und ihren
Beziehungen (Konnektoren) besteht.
272
2 Entwurfsqualität
sollen die Prinzipien und Heuristiken genauer betrachtet werden, da sie so
etwas wie den Erfahrungsschatz des objektorientierten Entwurfs darstellen.
Daher können aus ihnen Kriterien für einen guten Entwurf gewonnen werden.
• Prinzipien
Hier werden einige Prinzipien für den objektorientierten Entwurf, von
denen viele aus dem strukturierten Entwurf übernommen wurden kurz
vorgestellt.
• Heuristiken
Eine Heuristik ist eine Daumenregel, die meistens funktioniert, aber
nicht immer optimale Ergebnisse liefert. Daher ist eine Heuristik im
Gegensatz zum Prinzip nicht allgemein gültig, sondern es muss anhand
des Kontextes entschieden werden, ob ihr Einsatz an einer bestimmten
Stelle im Entwurf sinnvoll ist.
2.3
2.3.1
Beispiele für OOD-Qualitätsmodelle
Coad und Yourdon
• Coad und Yourdon [1] geben einige Kriterien an, die bei einer Entwurfsbewertung angewendet werden sollen. Ihrer Meinung nach werden Entwurfskriterien benötigt, um das Entwickeln eines schlechten Entwurfs
zu verhindern. Guter Entwurf bedeutet für sie eher, schlechte Eigenschaften zu vermeiden, als aus dem Stand einen perfekten Entwurf
abzuliefern. Letzteres sei nämlich völlig unrealistisch.
Kopplung (coupling) Coad und Yourdon haben zwei Arten der
Kopplung: durch Interaktion (entspricht der Kopplung durch Verwendung) und durch Vererbung. Um eine geringe Interaktionskopplung zu erreichen, wird vorgeschlagen, die Anzahl der versendeten
und empfangenen Nachrichten zuminimieren und die Anzahl der Parameter einer Nachricht auf drei zu limitieren. Die Delegation von
Nachrichten an andere Objekte wird als Ursache für unnötige Interaktionskopplung angesehen. Die Vererbungskopplung soll hingegen hoch sein. Die Vererbung spiegelt vornehmlich Generalisierungs/Spezialisierungsbeziehungen. Das Überschreiben von geerbten Attributen oder ein Erben ohne Erweiterung sind Indikatoren für eine
geringe Vererbungskopplung, da keine wirkliche Spezialisierung vorliegt.
273
Zusammenhalt (cohesion) Drei Ebenen des Zusammenhalts werden
unterschieden: Methode, Klasse und Vererbungshierarchie. Methoden sollten nur genau eine Funktion haben. Klassen sollten nur Attribute und Methoden haben, die aufgrund der Verantwortlichkeiten
der Klasse notwendig sind; und diese Attribute und Methoden sollen
zusammenhängen. In der Vererbungshierarchie schließlich sollen nur
echte Spezialisierungen vorkommen.
Wiederverwendung (reuse) Die Wiederverwendung vorhandener
Artefakte (z. B. Klassen, Komponenten, Bibliotheken, Entwürfe) kann
die Kosten senken und die Qualität erhöhen.
Klarheit (clarity) Der Entwurf muss verständlich sein, um seine Verwendung und Wiederverwendung zu fördern. Als Maßnahmen werden
die Verwendung eines einheitlichen Vokabulars, eines einheitlichen Stils
(insbesondere bei Schnittstellen) und die klare Zuordnung von Verantwortlichkeiten zu Klassen genannt.
Einfachheit (simplicity) Methoden, Objekte und Klassen sollen so
einfach wie möglich sein. Methoden sollten nur wenige Anweisungen
umfassen. Objekte sollten so wenig wie möglich andere Objekte kennen müssen, um ihren Zweck zu erfüllen. Klassen sollten möglichst
wenig Attribute und eine kleine Schnittstelle haben sowie klare Verantwortlichkeiten besitzen.
Größe (system size) Die Größe des Gesamtsystems sollte möglichst
klein sein, um die Handhabbarkeit zu verbessern. Je größer das System wird, desto größer wird das Risiko, dass das Entwurfsteam den
Entwurf nicht mit einem wohlstrukturierten, eleganten Ergebnis abschließen kann. Coad und Yourdon geben dafür eine Obergrenze von
etwa hundert Klassen an.
Eleganz (elegance) Die Autoren geben zu, dass dieses Kriterium von
allen am schlechtesten messbar ist. Weil der Begriff der Eleganz in der
Praxis immer wieder auftauche, müsse er aber von Bedeutung sein. Sie
geben zwei Beispiele für Eleganz an: wiederkehrende Muster im Entwurf und Ähnlichkeit der Entwurfsstruktur zur Struktur der Realität.
274
• Zur Entwurfsbewertung schlagen Coad und Yourdon Reviews vor. Zum
einen sollen sich diese an Szenarien orientieren, die mit den Klassen
durchgespielt werden. Außerdem sollten kritische Erfolgsfaktoren wie
Wiederverwendbarkeit, Effizienz und Implementierbarkeit geprüft werden.
2.3.2
Erni
• Ziel
Erni (1996; s. a. Erni und Lewerentz, 1996) definiert ebenfalls ein Qualitätsmodell nach dem FCM-Schema. Da das Modell zur Bewertung von
Rahmenwerken dienen soll, ist es auf den Bereich der Wiederverwendbarkeit beschränkt.
• Aufbau
Die Ebene der Kriterien wird in zwei Ebenen aufgeteilt: Entwurfsprinzipien und Entwurfsregeln. Auf dieseWeise kann das Modell die
zugrunde liegenden Prinzipien und Regeln reflektieren, so dass die Messungen auch gleich Verstöße gegen die Regeln und Prinzipien aufzeigen.
Falls die Werte bestimmter Metriken nicht im gewünschten Bereich
liegen, wird es dadurch für den Entwerfer einfacher, festzustellen, was
das Problem ist und was geändert werden sollte.
275
Figure 5: Qualitätsmodell von Erni
• Ergebnis
Zu den Metriken werden Schwellenwerte angegeben, die aus der Literatur oder aus Erfahrung stammen. Für manche Metriken ist es allerdings sinnvoller, eine erwünschte Richtung (z. B. so groß wie möglich)
anzugeben als einen oberen oder unteren Schwellenwert. Dann werden
Schwellenwerte gewählt, die sich aus dem Mittel und der Standardabweichung der Messwerte berechnen (im Beispiel die Summe aus Mittel und Standardabweichung). Mit Hilfe der Schwellenwerte können
die Messwerte in gut/schlecht oder akzeptabel/inakzeptabel unterteilt
werden.
276
2.3.3
Gillibrand und Liu
• Ziel
Gillibrand und Liu geben ein rudimentäres Qualitätsmodell für den
objektorientierten Entwurf an. Zu diesen Faktoren werden Kriterien
angegeben, für die wiederum eine Reihe von Metriken angegeben wird.
• Aufbau
Das Modell enthält die drei Faktoren Zuverlässigkeit, Komplexität und
Wiederverwendbarkeit. Abbildung 6. zeigt den Aufbau des Modells.
Der Begriff Zuverlässigkeit wird hier in einem völlig anderen Sinne verwendet: Er bezeichnet die Korrektheit des Entwurfs in Bezug auf die
Spezifikation. Für die anderen beiden Faktoren wird keine Definition
angegeben, da wohl irgendeine übliche Definition angenommen wird.
Übrigens bedeutet eine höhere Zuverlässigkeit oder Wiederverwendbarkeit eine höhere Qualität, während eine höhere Komplexität eine
niedrigere Qualität bedeutet. Eine solche Gegenläufigkeit der Faktoren
ist -schon aus psychologischen Gründen -keine gute Idee. Statt Komplexität wäre wohl Einfachheit die bessere Wahl gewesen.
Figure 6: Qualitätsmodell von Gillibrand und Liu
• Ergebnis
Die Kriterien werden nicht näher erläutert, dafür die Metriken ausführlich. Die Bewertung eines Kriteriums ergibt sich aus den Werten
seiner Metriken, die gewichtet werden sollen. Konkrete Gewichte geben
die Autoren aber nicht an. Eine Gewichtung soll ebenfalls erfolgen, um
aus den Werten der Kriterien Werte für die Faktoren zu erhalten. Explizite Zusammenhänge zwischen Faktoren und Kriterien fehlen aber in
277
der Beschreibung, Gewichte werden auch nicht genannt. Es gibt zwar
eine Diskussion, welche Metriken Einfluss auf welche Faktoren haben
-wie diese Einflüssse mit den Kriterien zusammenhängen, bleibt aber
unklar. Es wird nur gesagt, dass alle fünf Kriterien für jeden Faktor
relevant sind.
2.3.4
Bansiya und Davis
• Zeil
Bansiya und Davis haben ein hierarchisches Qualitätsmodell für den
objektorientierten Entwurf namens QMOOD (Quality Model of ObjectOriented Design) entwickelt.
• Aufbau
Das Modell besteht aus drei Ebenen: Qualitätsattribute, Entwurfseigenschaften und Metriken.Basis der Bewertung ist ein in C++ dokumentierter Entwurf.Auf diesen Dateien werden mit Hilfe des Werkzeugs
QMOOD++ Metriken erhoben. Jede dieser Metriken ist genau einer
Entwurfseigenschaft zugeordnet. Die Entwurfseigenschaften beeinflussen die Qualitätsattribute positiv oder negativ. Für die Stärke
des Einflusses geben die Autoren Gewichte an, so dass sich aus den
Metriken Qualitätskennzahlen für die Qualitätsattribute berechnen
lassen.
• Ergebnis
Die Gesamtbewertung ergibt sich durch Aufsummieren der Qualitätskennzahlen.
278
Figure 7: Qualitätsmodell von Bansiya und Davis
2.4
Zusammenfassung der Exprimente
Wie die vorgestellten Beispiele zeigen, gibt es kein einheitliches Modell zur
Bewertung objektorientierter Entwürfe. Es gibt zwar einige Kriterien, die
öfter auftreten (z. B. Kopplung und Zusammenhalt) Diese unterscheiden
sich aber jeweils in ihren Definitionen. In der Struktur der Modelle ist keine
klare Trennung der Detaillierungsebenen (Methode, Klasse) erkennbar.
Außerdem werden die Systemebene kaum und die Paketebene gar nicht
betrachtet. Stattdessen ist die Sichtweise meist auf Klassen und ihre
Bestandteile fokussiert. Die Beziehungen zwischen Klassen (Vererbung,
Assoziation) werden selten explizit und oder gar detailliert betrachtet.
Nur die letzten drei Modelle enthalten eine Quantifizierung. Die Quantifizierung bei Gillibrand und Liu ist allerdings nur fragmentarisch
dokumentiert und daher unbrauchbar. Außerdem deckt das Modell nur
einen kleinen Teil der relevanten Qualitätsattribute ab. Nur bei Bansiya
und Davis gibt es eine Quantifizierung für alle Ebenen.
279
3
Ein Modell für den Objektorientierten Entwurf
Der folgende Abeschnitt beschreibt das Object-oriented Design
Model(ODEM). Um einen objektorientierten Entwurf bewerten zu können,
muss man zunächst festlegen, was man genau darunter versteht. Ralf
Reißing hat in seiner Abhandlung [4] das Object-Oriented Design Model
(ODEM) entwickelt. ODEM enthält die Teile des objektorientierten Entwurfs, die als für die Bewertung relevant erachtet werden. Dabei wird von
Entwurfsartefakten ausgegangen, die typischerweise vorhanden sind. ODEM
kann auch für die formale Definition von Metriken auf diesen Artefakten
verwendet werden.
3.1
Grundlagen
UML ist der Standard für die Darstellung Objektorientierter Entwurf, Und
daher muss eine Integration von UML in ODEM stattfinden. Daher baut
ODEM auf den Informationen auf, die sich aus einer Entwurfsdarstellung in
UML, d. h. einem UML-Modell, gewinnen lassen.
Abbildung 8.
zeigt die konzeptionelle Struktur von ODEM. ODEM
beruht auf dem UML-Metamodell. Für die Verwendung in ODEM wird
das UML-Metamodell auf den tatsächlichen Bedarf reduziert. Zusätzlich
werden nützliche, aus den Bestandteilen des UML-Metamodells abgeleitete
Modellelemente eingeführt. Diese dienen vor allem dazu, als Abstraktionsschicht die Komplexität des UML-Metamodells nach außen zu verbergen.
Außerdem sind sie praktisch bei der Definition von Metriken.
Figure 8: Konzeptionelle Struktur von ODEM
280
4 Zusammenfassung
3.2
Kernelemente von Object-Oriented Design Model
(ODEM)
Abbildung 9. zeigt die Kernelemente von ODEM mit ihren Attributen und
Beziehungen als UML-Klassendiagramm.
Figure 9: Der Kern von ODEM
4
Zusammenfassung
Diese Ausarbeitung beschäftigt sich nicht nur die Begriffe des objektorientierten Entwurfs ,sondern auchmit der Bewertung des Objektorientierten
Entwurfs.
Zuerst führen die Begriffe der Objektorientierung und Entwurf im ersten
Kapitel ein. Die Objektororientierung haben drei Eigenschaften: Objekte,Klassen und Vererbung. Der Begriff des Objekts spielt die zentrale
Rolle. Eine Klasse definiert die Attribute und Methoden ihrer Objekte, und
Vererbung ist eine Beziehung zwischen Klassen. Dann weiter beschäftigt sich
mit verschiedenen Aspekten des objektorientierten Entwurfs (object-oriented
design, OOD). Es wird definiert, was Entwurf ist und welche Arten von
Entwurf es gibt.
Anschließend wird auf Entwurfsregeln ( Prinzipien und Heuristiken ) des
objektorientierten Entwurfs eingegangen. Diese enthalten Erfahrungswissen,
281
wie man zu einem guten (bzw. besseren) Entwurf kommt.Dazu wird vier
Beispiele vorgestellt. Jedes Beispiel wird aus das Ziel, der Aufbau und das
Ergebnis besteht. Dazu kann man gut verstehen, wie die objektorientierten
Entwurf läuft. Und am Ende zeige ich, was die ODEM ist und wie die
aufbauen.
References
[1] Briand, L.; Bunse, C.; Daly, J.: A Controlled Experiment for Evaluating
Quality Guidelines on the Maintainability of Object-Oriented Designs.
IEEE Transactions on Software Engineering, 27 (6), IEEE Press, 2001.
[2] Glinz,M.: Spezifikation und Entwurf von Software
[3] Chernuchin,D.;Dittrich,G.: Aspekte der Objektorientierten Modellierung am Beispiel Evolutionärer Algorithmen
[4] Reißing, R. (2001): Towards a Model for Object-Oriented Design Measurement. In: Brito e Abreu, F. et al. (eds.):Proceedings of the 5th
International ECOOP Workshop on Quantitative Approaches in ObjectOriented Software Engineering(Budapest, June 2001), 71-84.
[5] Entwurfsmuster aus Wikipedia, der freien
”http://de.wikipedia.org/wiki/Entwurfsmuster”
Enzyklopödie:Von
[6] http://de.wikipedia.org/wiki/Entwurf
282
Experimente auf Designebene
Yu Yin
Betreuer: Dirk Wilking
Abstract
Der Begriff der Empirie stammt aus dem Griechischen und
bedeutet ”auf Erfahrung” beruhend. Er steht damit im Gegensatz zur
Theorie. ”Empirisch” bedeutet somit aus der Erfahrung, Beobachtung
oder dem Experiment entnommen. Unter empirischer Softwaretechnik
versteht man also die praktische Durchführung von Experimenten,
Fallstudien, usw. mit dem Zweck, vorher aufgestellte Hypothesen
zu ueberprüfen. In diesem Kapitel werden nach einer allgemeinen
Erklärung des Aufbaus und des Ablaufs einer empirischen Studie
drei Moeglichkeiten empirischer Vorgehensweisen genauer erklärt:
Experimente, Fallstudien und Surveys. Für jede Vorgehensweise
wird die Durchführung beschrieben und anhand eines Beispiels
verdeutlicht.
1
Einleitung
Der Zweck dieses Experimentes ist, dass es die Auswirkung des Verwendens
von OCL auszuwerten, und mit UML kombiniert.(Kategorie, Diagramme,
usw). Wie kann man ein Experiment aufbauen. Zuerst muss man wissen,
was die wichtigsten Schritte bei einem Experiment sind.( Fragestellung>Hypothesen->Versuchsplan->Stichprobe->Durchführung-> Auswertung
der Daten->Schluss auf Hypothese->Bericht).
• OCL
Mit der OCL(Object Constraint Language)steht jetzt eine Sprache
zur Verfügung, die sich von herkömmlichen formalen Spezifikationssprachen deutlich unterscheidet. Die Betonung liegt hier weniger
auf der mathematischen Fundierung als auf der praktischen Anwendbarkeit. Mit Hilfe der OCL können präise Einschränkungen und
Bedingungen mit wenig Aufwand zu einem UML-Modell hinzugefügt
werden. Die Ursache für diesen pragmatischen Ansatz ist sicher in der
Herkunft dieser Sprache zu suchen: Sie ging aus einer Entwicklung der
Firma IBM hervor und ist seit der Version 1.1 Bestandteil der UML
der Object Management Group (OMG) ([1], [2]).
Die OCL hat gegenüber herkömmlichen Spezifikationssprachen
den wesentlichen Vorteil, dass es mit ihr möglich ist, ein bestehendes
UML-Modell inkrementell zu erweitern. Somit ist es von Dokumenten
der objektorientierten Analyse ausgehend nicht mehr nötig, die
Semantik des Modells, vor allem die in ihm definierte Typ- bzw.
Klassenhierarchie, umständlich in eine äquivalente Darstellung in
der Spezifikationssprache umzusetzen. Ausserdem können gezielt
diejenigen Aspekte präzise beschrieben werden, die aus den UMLDiagrammen nicht klar hervorgehen([3]). All dies kann in einer
wesentlich kompakteren Schreibweise ausgedrückt werden, als das bei
anderen Sprachen möglich ist. Das wird unter anderem durch eine
Bibliothek von vordefinierten Typen erreicht.
Ein anderer Punkt, der OCL zur breiteren Anwendung tauglich
macht, ist die Einfachheit der Sprache. Während bei anderen Spezifikationssprachen eine umfangreiche Vorbildung in mathematischer
Logik zum Verständnis erforderlich ist, ist OCL für einen mit Programmiersprachen vertrauten Leser nahezu intuitiv verständlich,
was man von anderen Spezifikationssprachen kaum behaupten kann.
Zusammenfassend kann aber trotzdem gesagt werden, dass die OCL
durchaus geeignet ist, in realen Projekten Verwendung zu finden, ohne
dass das durch die überdurchschnittlichen Sicherheitsansprüche eines
solchen projekts begründet werden müsste.
Der wesentliche Vorteil liegt in dem vergleichsweise geringen Aufwand,
der hiermit verbunden ist. Bis mit der OCL formale Spezifikationsmethoden Einzug in den Alltag der Softwareentwicklung halten,
sind aber noch einige Hürden zu bewältigen. Denn als reine Dokumentationssprache, die als Interpretationshilfe zu UML-Diagrammen
hinzugefügt werden kann, wird sich diese Sprache sicherlich nicht
284
1 Einleitung
durchsetzen.
OCL ist Bestandteil der UML und dient unter anderem der textuellen
Spezifikation von Invarianten in Klassendiagrammen, von Bedingungen
in Sequenzdiagrammen oder der Formulierung von Vor- und Nachbedingungen für Methoden. Ihre Syntax ist an die Programmiersprache
Smalltalk angelehnt. Sie ist seit der UML-Version 1.1 Bestandteil der
UML. Es werden 4 Arten von Constraints unterschieden: Invariants
müssen zu jeder Zeit für eine Instanz, Typ oder Interface gelten.
Preconditions müssen gelten zu dem Zeitpunkt an dem die Ausführung
der zugehörigen Operation beginnt. Postconditions müssen zu dem
Zeitpunkt gelten an dem die Ausführung der zugehörigen Operation
endet. Guards müssen gelten wenn ein Zustandsübergang beginnt.
Ein Constraint ist immer definiert im Rahmen eines Kontext. Dies
ist ein beliebiges Modell Entity, wie z.B. eine Klasse, ein Typ, ein
Interface oder eine Komponente. Man unterscheidet den Kontext Typ
und die Kontext Instanz.
Auf letzteren beziehen sich die Angaben eines Constraints. Z.B.
er kann festlegen, dass für eine Instanz der Klasse Banane der Wert
des Attributs Krümmung nicht grösser als X sein darf. Object
steht hier für eine Komponente eines beliebigen Systems, diese soll
genauer spezifiziert, definiert oder beschrieben werden. Constraint
steht für eine Begrenzung oder Einschränkung, diese kann maximale
oder minimale Werte annehmen. Beispielsweise die maximale Anzahl
gleichzeitiger Zugriffe auf eine Datenbank, oder die maximale Höhe
eines Bauobjektes. Language steht hier nicht für eine formale Computersprache, sondern vielmehr für eine auf jede Implementierung
anwendbare weniger formale Sprache.
• UML
Unified Modeling Language (häufig mit UML abgekürzt) ist eine
von der Object Management Group entwickelte und standardisierte
Beschreibungssprache, um Strukturen und Abläufe in objektorientierten Softwaresystemen darzustellen. Im Sinne einer Sprache
definiert die UML dabei Bezeichner für die meisten Begriffe, die im
Rahmen der Objektorientierung entstanden sind, und legt mögliche
Beziehungen zwischen diesen Begriffen fest.
Die UML definiert des weiteren grafische Notationsweisen für
diese Begriffe und für Modelle von Software oder anderen Abläufen,
285
die man in diesen Begriffen formulieren kann. Die UML wurde am
19. November 1997 von der OMG als Standard akzeptiert und wird
seit dem von ihr weiterentwickelt. Im Juni 2003 wurde die jüngste
Version der UML, die Unified Modeling Language 2.0 oder UML2,
von der OMG als Entwurf veröffentlicht. Sie wurde im März 2005
verabschiedet.
Die UML beschreibt eine Menge von Diagrammen um die Architektur und Modellierung zu beschreiben. Verschiedene Ansätze
der Wissensrepraesentation verwenden ebenso die UML, insbesondere
UML Klassendiagramme. Die Sprache OCL um die Semantik von
UML Diagrammen formal beschreiben zu können. In dieser Arbeit
sollen die UML basierten Ansaetze zur Wissensrepraesentation insbes.
unter Verwendung der OCL untersucht werden.
• Design
Das Wort Design, zu Deutsch Gestaltung, bedeutet meistens Entwurf
und Formgebung, im Regelfall auch unter dem Gesichtspunkt der
Schönheit. Es ist ein Lehnwort aus dem Englischen, das wiederum
aus dem Lateinischen abgeleitet ist (designare = (be)zeichnen) und
in viele europäische Sprachen Eingang gefunden hat. Im Englischen und Französischen bedeutet design ”Gestaltung” oder ”Entwurf”,
während das italienische disegno ”Zeichnung” bedeutet. Im Gegensatz
zur deutschen Bedeutung des Design-Begriffes, die eher im formal liegt.
2
2.1
Experiment
Definition des Experimentes
Ein Experiment (Versuch, Beweis, Prüfung, Probe) ist ein wissenschaftlich
aufgebauter Versuch zur zielgerichteten Untersuchung einer unter definierten
Bedingungen reproduzierbar hervorgerufenen Erscheinung. Das Experiment
ist neben der genauen Beobachtung die wichtigste wissenschaftliche Methode,
um etwas über die Realitaet zu erfahren.
2.2
Planung und Design
Die Variablen, Prozeduren, Kontrollmechanismen und Auswahlverfahren zur
zufälligen Gruppenbildung werden in diesem Prozess festgelegt. Das Design
umfasst drei Aktivitäten, die iterativ durchgeführt werden:
286
2 Experiment
• Festhalten des Ziels und informelle Formulierung der Hypothesen
• Definieren der Variablen des Experiments
• Auswählen eines Designs mit minimalen Kosten
2.3
Implementierung und Vorbereitung
Das ist auch Vorbereiten aller benoetigten Materialien und Treffen organisatorischer Massnahmen.
2.4
Durchführung
Alle Qualitätskontrollen müssen angegeben werden, die die Vollständigkeit
und Genauigkeit der Datenerfassung sicherstellen.
Bei Surveys muss
auch die Antwortrate erfasst und veröffentlicht werden. Weiters muss die
Repräsentativität der Antworten untersucht werden und der Einfluss der
nicht-Antworten. Die Ursachen für nicht-Antworten sind wichtig, da sie die
Ausgewogenheit der Ergebnisse beeinträchtigen können. Manchmal ist es
sinnvoll, die nicht-Antworten selbst zu untersuchen und bei einem Sample
die genauen Gründe herauszufinden, z.B. durch demographische Analysen
oder mittels telefonischer Kurzinterviews.
Bei beobachtenden Studien und Experimenten muss zusätzlich die Anzahl der Abbrecher erfasst werden. Es gibt verschiedene Gründe, warum
Subjekte aus einer Untersuchung aussteigen bevor diese abgeschlossen
ist: Zum Beispiel werden Subjekte einem anderen Projekt zugeteilt, sie
verlassen die Firma oder haben einfach kein Interesse weiter an der Studie
teilzunehmen. Solche Situationen müssen auf jeden Fall protokolliert werden.
2.5
Analyse der gewonnenen Daten
Es muss sichergestellt werden, dass die Daten die Anforderungen erfüllen,
die die durchgeführten Tests an sie stellen. Die verschiedenen statistischen
Verfahren stellen oft bestimmte Anforderungen an die Verteilung der untersuchten Daten. Es hat keinen Sinn, ein Verfahren anzuwenden, wenn diese
Anforderungen nicht erfüllt werden.
287
2.6
Aufbereitung und Interpretation der Daten und
Veröffentlichung von Ergebnissen
Alle statistischen Methoden müssen beschrieben oder Referenzen auf
entsprechende Dokumente angegeben werden. Nur das verwendete Statistikpaket zu nennen ist hier nicht ausreichend, obwohl es natürlich auch
genannt werden sollte.
Man sollte, wenn möglich, die Rohdaten veröffentlichen. Da Studien
im Software Engineering oft im Rahmen realer Projekte durchgeführt
werden, können die Projektdaten natürlich nicht immer veröffentlicht werden. Dann sollten diese zumindest vertrauenswürdigen oder unabhängigen
Auditoren zugänglich gemacht werden. Jegliche Einschränkungen der Studie
sollen diskutiert und angegeben werden.
3
Beispiel des Experimentes
• Definition des Experimentes
Der Zweck dieses Experimentes ist, die Auswirkung des Verwendens
von OCL auszuwerten. Sie sind jedoch nicht in der Lage, eine
Kosten-Nutzen-Analyse durchzuführen, da die Aufwand in diesem
Experimentdesign konstant ist. Dieses ist ein typisches Experiment,
in dem Zeit normalerweise begrenzt ist, und die Studie werden in der
industriellen Einstellungen wahrscheinlich angefordert, um die Kosten
von OCL festzusetzen.
Analyse des Dokumentes ist das erste UML Modell, das in den
meisten Methodologie produziert wird. Und Design ist unterschiedlich,
weil der wichtige Schwerpunkt nicht architektonische Informationen
besorgt sondern die Funktionalität und die Logik des System ist.
• Planung und Design
In diesem Experiment untersucht man die Auswirkung von OCL nach
zwei abhängige Variablen:
Comprehension (C): Diese Variable nimmt die Fähigkeit der Themen,
um Fragen über die System Funktionalität und die Logik zu beantworten. Die übersicht sowie die Anzahl der korrekten Antwort wird in
einem Ausdruck von Fragebogen aufgezeichnet.
Maintainability (M):
288
3 Beispiel des Experimentes
Diese Variable konzentriert auf die Fähigkeit der Themen, um
festzustellen, welche Elemente der UML-Modelle nach Analyse die
änderung durchmachen müssen, die auf Beschreibungen basiert.
Dieses wird, während einer eine Stunde Session, gründete auf einem
sorgfältig entworfenen Fragebogen gemessen, in dem eine Anzahl von
Änderungen beschrieben werden und Themen erwartet werden, alle
betroffenen vorbildlichen Elemente zu verzeichnen.
Man kann auf die obere genannte Variablen die folgende Hypothese(H0) formulieren. Es gibt keinen Unterschied bezüglich des
Erfassens und der Haltbarkeit zwischen den Themen, die auf den UML
Dokumenten arbeiten, welche die OCL Bedingungen einschliessen und
ausschliessen (unten bezeichnet als variable Methode). Die alternative
Hypothese (h1) ist, dass OCL Leistung für unsere zwei abhängige
Variablen beeinflusst. Um exakter zu sein, sollte h1 angebunden
werden: man erwartet OCL, um Leistung zu erhöhen.
Ob OCL auf Datenanalyse benutzt wird, wollte man die Daten über
die Fähigkeit der Themen in Bezug auf UML modellieren(bezeichnete
Fähigkeit unten). Es ist so wichtig, dass die Schwankungen der
menschlichen Fähigkeit erhebliche Unterschied bezüglich der Resultate
verursachen. Dieses kann man eine Auswirkung von OCL auf unsere
abhängige Variablen verhindern. Man messt folgliche Fähigkeit, in
dem man die Grade der Kursteilnehmern von einem vorhergehenden
UML verwendet und direkt zur Handaufgaben denkt.
• Implementierung und Vorbereitung
Es gibt insgesamt 38 Kursteilnehmern, die in unserem registriert wurden. Die Kursteilnehmern waren mit den Konzepten der Verträge (vor
und Pfosten-Zustände) die konstante Zustand und der konstante Klasse
vertraut. Man sieht, keine Notwendigkeit um Kursteilnehmern auszusortieren, da Schwankungen der Fähigkeit auch in der industriellen Einstellungen anwesend sind. Das Experiment war ein Teil einer Übungen
des Kurses. Kursteilnehmern wurden erklärt, dass sie nicht auf Leistung geordnet würden, aber sie wurden erwartet, um ihre Aufgaben in
einer professionellen Weise durchzuführen, um die Punkte zu erreichen.
Die Punkte wurden Kurs zugewiesen. Die Kursteilnehmern beachteten,
dass man versucht, die Auswirkung von OCL sowie das Verbessern ihres
praktischen Trainings in UML auszuwerten. Aber sie berücksichtigten
nicht die genauen Hypothesen, die man prüft, oder welche Resultate
hofft man, zu erreichen.
289
• Durchführung
Sie spezifizierten zuerst die Plannung des Experimentes: Die Kursteilnehmern wurden bis eine von 4 Gruppen zugewiesen, und die Aufgaben,
die sie über 4 Kurse(Lab)sind, und der Auftrag der Aufgaben werden
in Fig.1 zusammengefasst. Die Reihen stellen die vier folgenden Kurse
dar, die Kursteilnehmern (jeder Kurs, der eine Woche auseinander
ist. d.h jeder Kurs arbeitet selber eine Woche) die drei Aufgaben
durchzumachen. Sie durchführten, während die Spalten die 4 Gruppen
der Themen sind.
Figure1 stellen für jede Gruppe dar, welches System sie bearbeiten und ob sie OCL Begrenzungen haben. Merken Sie, dass dieses
Papier nur die Resultate dargestellt, die auf Kurse 2 und 4 bezogen
werden. Ob OCL die Entdeckungen von Mangel in den UML-Modellen
hilft, werden dargestellt [9].
Dieses Experiment betrifft nur einen Faktor mit Effekt vom Interesse für uns, ob OCL in die Datenanalyse verwendet wird. Die
Kursteilnehmern wurden folglich gruppiert, (”in die Blöcke” bestanden
aus 20 und 18 Kursteilnehmern), ob sie einen minimalen Grad von
B im vorhergehenden Kurs auf UML und OCL erreicht hatten.
Anerkanntermassen können sie auch mit anderer Weisen machen.
Aber der Fokus ist hier auf UML die Fähigkeit modelliert und als
Ausbilder ihrer vorhergehenden Kurse auf diesem Thema glauben sie,
dass es die beste Alternative ist. Jede Gruppen wurde beliebig nach
dem Zufall Kursteilnehmern von beiden Blöcken in den fast gleichen
Anteilen zugewiesen.
Es war auch für uns wichtig, um die Datenanalyse zu erleichtern,
dass jede Gruppen ungefähr von der gleichen Grösse ist. Für jede
Aufgabe arbeitete jedes Thema einzeln auf jedem der zwei Systeme
mit UML und OCL in einem Fall und nur UML im anderen. Jeder
Kursteilnehmer führte alle Aufgaben durch, die betreffend Erfassen
und Haltbarkeit auf beiden Systemen geplant wurden. Die Kursteilnehmern wurden auch am Zusammenarbeiten verhindert und dieses
könnte leicht überwacht werden, während Aufgaben in einem Kurs
durchgeführt wurden.
Das Grundprinzip dieser Arbeit war auf beiden Systemen: (1)
Sie maximieren die Zahl der Datenpunkten (Beobachtungen), um
290
statistische Energie zu erhöhen. (2)Sie versichern, dass die Unterschiede bezüglich der Kompliziertheit der Systeme nicht die Resultate
(zwar wählten uns Modelle ”der ähnlichen” Kompliziertheit) beeinflusst
wurden und (3) die Gelegenheit geben jedem Kursteilnehmer, das
gleiche Material zu erlernen. Jedoch wenn Versuchspersonen gebeten
werden, führen ähnliche Aufgaben der mehrmals (z.B. Auswirkung
Analyse) durch und verwenden die gleichen Techniken (z.B. OCL
Verträge). Wir sind abhängig von Lernen- oder Ermüdungeffecten
und mann muss sie sicherstellen nicht die Resultate verwirren. Dieses
wurde in zwei Möglichkeiten getan. Zuerst verwendeten erste Gruppen
OCL, das erste mal sie die Aufgabe durchführten, während die zweite
Gruppen so das zweite mal herum, dann kann man nicht mit der
Effekten von OCL verwirren. Sowie in Abschnitt (Analysis Procedure)
beschrieben, erklärt unser Verfahren von Datenanalyse auch Lerneffekte.
Sie verwendeten 4 Gruppen Teilnehmern anstelle von 2, um die
Effekte zu vermeiden (z.B. Effekt der Ermüdung). z.B. Wenn alle Teilnehmer an Gruppe 1 zuerst System mit OCL verwendet haben würden
(und dann das CD-System ohne OCL), während alle Teilnehmer an
Gruppe 2 mit non-OCL Dokumenten auf dem CD-System (und dann
mit OCL)begonnen haben würden. Sie könnten beobachten, dass
Leute in Gruppe 2 mehr Zeit das Wissen von UML und von OCL haben.
Anderes Resultat unserer Design ist, dass alle Gruppen jedes der
zwei Systeme zweimal in einer Reihe benutzen, manchmal mit OCL
zuerst oder zweite anfangen. Man kann folglich fragen, ob dieses eine
Drohung zur Gültigkeit der Resultate ist. Zuerst ist es wichtig zu
beobachten, wenn das System zweimal in einer Reihe benutzt wird.
Er soll eine andere Aufgabe durchführen, und die gesammelten Daten
werden geteilt und analysiert. Wenn es einen System die Effekt des
Lern gibt, können Gruppe 1 von Kurs 1 zur Kurs 2 gehen. Dieses ist
eine bessere Erfassen- und Haltbarkeitsleistung. Ausserdem erwarten
sie dass System Lerneffekt, um schwach zu sein, während die Kurse
eine Woche auseinander stattfinden und Kursteilnehmern nicht Zugang
zu den Dokumenten zwischen Kurse haben.
• Analyse der gewonnenen Daten
Sie beginnen zuerst mit etwas einfacher einleitender Analyse, die hilft,
unsere folgenden Analyse Schritte zu rechtfertigen. Abschnitte ( der
Prozess von Kurs 2 (C),der Prozess von Kurs 4 (C), die Erhaltung
291
Figure 1: Design und Ausführung
von Kurs 2 (M) und die Erhaltung von Kurs 4 (M)) stellen dann
die Resultate der Datenanalyse hintereinander mit beschreibenden
Standardstatistiken dar[10]. Der Hauptgrund für das Betrachten jedes
Kurses soll separat die Lerneffekte erklären, die durch unsere einleitende Analyse vorgeschlagen werden, wenn man die Forschung Frage
über die Auswirkung von OCL beantwortet. In jedem Unterabschnitt
zeigen die Zahl von Tabellen der Statistik und Mittelwerte(Mittel).
Eröffende Analyse (Frage zu beantworten) soll geben, dass zwei
Leute in eine Gruppe T-test durchführen, der auf die Spielergebnisse
aller Kursteilnehmern basiert, wenn sie UML und OCL, und nur-UML
verwendet haben. Fig.2 zeigt, dass OCL eine statistisch bedeutende Auswirkung für Erfassung hat, obwohl beide Leuter (kleinen)
Unterschied von Spielergebnisse haben.
Figure 2: T-test zu Vergleich zwischen UML und OCL, und nur-UML
Um zu verstehen, ob Lerneffekte und der Effekte von OCL in diesem
Fall existieren. Sie führten einen T-test durch (die Fig. 4). Ob der
Unterschied der Spielergebnisse zwischen UML und OCL und nur-UML
haben, wurde OCL zuerst in Kurs 2 (d.h. OCL wurde benutzt, dass
es erste mal in der Aufgabe durchgeführt, bezeichnet als O-N) dann in
Kurs 4 verwendet.(d.h. OCL wurde verwendet, dass es zweite mal in
292
der Aufgabe durchgeführt wurde, bezeichnet als N-O). Fig.3 zeigt die
durchschnittliche Unterschied (d.h. Sie haben Unterschiede bezüglich
der Prozentsätze der maximalen Spielergebisse)zwischen N-O und O-N
sowie P-Werte.
Figure 3: die Auswirkung von Probe durch T-test über die Aufgabe
Fig.3 schlägt vor, dass es in OCL angewendet wird, einen bedeutenden
Effekt auf dem Unterschied zwischen UML und OCL und nur-UML
hat. Das heisst, dass der Profit von OCL O-N Kursteilnehmern kleiner
als N-O Kursteilnehmern ist. Zu uns schlägt dieses vor, dass im O-N
Fall anderen Effekt erstellt wird. Der Effekt kann nur Lerneffekte
sein, da alle weiteren plausiblen Effekte gesteuert worden(d.h. System,
Fähigkeit). Aus diesem Grund machen sie die Datenanalyse jedes
Kurses auf eine unabhängige Art und Weise, damit sie ein ähnliches
Niveau des Trainings und der Erfahrung bekommen.
der Prozess von Kurs 2 (C)
Die Resultate sind in Kurs 2 Erscheinen der Erfassung nur ein
schwacher Effekt(Pwert = 0.08 und E2=0.097)für Fähigkeit(Fig.5
ANOVA Tabelle-Kurs 2(C)). Es ist auch in Fig.4 (Beschreibung von
Statistik des Kurses 2(C)) und in Fig.6 (Graph der Mittelwerte von
Kurs 2(C)) sichtbar. Es ist interessant, dass alle Werte in Fig.4 unter
10 sind, ob OCL verwendend oder nicht hat. Dies heisst, dass die Fragen weniger als 50 Prozent richtig beantwortet wurden. Sogar haben
die technische Kursteilnehmern nicht gewohnt, die ausgebildete 4 Jahr
haben.
der Prozess von Kurs 4 (C)
In Kurs 4 sind die Resultate zu Kurs 2 sehr unterschiedlich (Fig.7
Beschreibung von Statistik des Kurses 4(C) und Fig.8 ANOVA
Tabelle-Kurs 4(C)).
Fähigkeit und Methode (OCL) haben offenbar einen positiven
Effekt (Pwert = 0.035 und 0.003, beziehungsweise). Über die Logik
293
Figure 4: Beschreibung von Statistik des Kurses 2(C)
Figure 5: ANOVA Tabelle-Kurs 2 (C)
Figure 6: Graph der Mittelwerte von Kurs 2 (C)
294
des Systems fragt man, ob sie eine niedrige oder hohe Fähigkeit haben
(der Interaktion Effekt ist nicht bedeutend). Der Grösse Effekt der
Methode ist E2=0.27 stärker als der Effekt der Fähigkeit (E2=0.12).
Dieses Resultat wird weiter von Figure 9 veranschaulicht, dass der
Effekt von OCL ähnlich ist, ob Kursteilnehmern eine niedrige oder
hohe Fähigkeit haben. Der Unterschied zwischen Kurs 2 und Kurs 4
kann durch das Vergleichen der Resultate für die Erfassung erklärt
werden.
Die Analyse des übersichtlichen Fragebogens für Kurs 4 ist mit den
ANOVA Resultaten gleichbleibend: Die Themen, die OCL verwenden,
verbrachten weniger Zeit, die das System versteht (Man bekommt pvalue=0.007, mean(OCL)=3.87 gegen mean(non-OCL)=2.86) und für
die Fragen ist dieser Prozess leichter zu antworten (p-value=0.00003,
mean(OCL)=3.5 gegen mean(non-OCL)=1.92).
Sie merken, dass diese Resultate nicht in den Fragebögendaten
von Kurs 2 beobachtet wurden. Die Spielergebnisse sind unterschiedlich zwischen OCL und die non-OCL Gruppen. Ausserdem ist
die Fragen, die richtig beantwortet werden, sind die richtige Antworten
für die OCL Gruppe erheblich höher.
Man bekommt die Mittelwerte, die die Fähigkeiten von Kursteilnehmern in Kurs 4 (10, 13) und in Kurs 2 (7.1, 9.4) sind. (Fig.9): Die
Verwendung von OCL erhöht sich auf Durchschnitt um 46 Prozent und
43 Prozent. Diese Zahlen sind korrekter Antworten für die hohen und
niedrigen Fähigkeiten von Kursteilnehmern. Diese Resultate schlägt
vor, dass die Leute in Kurs 4 besser vorbereitet wurden. Man benutzt
aus OCL besser zu verwenden. Es kann durch die Tatsache erklärt
werden, die sie zusätzliche Zeit hatten, das Verständnis von OCL zu
reifen, und die Aufgabe wurden ausgeführt.
die Erhaltung von Kurs 2 (M)
Wie hat OCL keinen Effekt für Erfassen in Kurs 2 (Fig.11 ANOVA
Tabelle-Kurs2(M) Figure 12 Graph der Mittelwerte von Kurs 2(M)).
Die Resultate zeigen auch den Durchschnitt wie Erfassen, dass nur 30
Prozent richtig gekennzeichnet werden. Die Beschreibung von Statistik
des Kurses2(M) Figure 10) ist offenbar Anzeige, trotz ihres Trainings
295
Figure 7: Beschreibung von Statistik des Kurses 4(C)
Figure 8: ANOVA Tabelle-Kurs 4(C)
Figure 9: Graph der Mittelwerte von Kurs 4(C)
296
und sie nicht völlig für die Aufgabe der zur Hand vorbereitet haben,
weil auf Dokumenten solcher Skala Kompliziertheit sind. Dieser kann
ein Grund sein, warum man keinen Effekt von allen Fähigkeit und
Methode sieht.
Figure 10: Beschreibung von Statistik des Kurses2(M)
Figure 11: ANOVA Tabelle-Kurs2(M)
Figure 12: Graph der Mittelwerte von Kurs 2(M)
die Erhaltung von Kurs4 (M)
Die Resultate sind für Kurs 4 sehr unterschiedlich zu Kurs 2. Die
Resultate (Fig.14 ANOVA Tabelle-Kurs4(M)) zeigen, dass Fähigkeit
und Methode (OCL) eine bedeutende Auswirkung haben (pvalue =
0.006 und 0.029, beziehungsweise).
297
Die ANOVA Resultate zeigen nicht einen bedeutenden Interaktion Effekt, obwohl Fig.15 scheint, dass der Effekt von OCL für
Kursteilnehmern der niedrigen Fähigkeiten stärker als er für Kursteilnehmern der höheren Fähigkeiten ist (er erhöht sich auf Durchschnitt
um 122 Prozent und 13.3 Prozent. Diese Zahlen sind korrekten
Antworten.). Der Grösse Effekt der Auswirkung der Fähigkeit und die
Methode sind E2=0.22 und E2=0.13, beziehungsweise. So sehen sie,
dass die Auswirkung von OCL noch praktisch bedeutend ist, da sie
60 Prozent der Auswirkung der Fähigkeit darstellt. Die Unterschiede
bezüglich der Resultate werden zwischen Kurs 2 und Kurs 4 durch
die Fragebogenanalyse erklärt, die in dem Abschnitt( der Prozess
von Kurs 4)dargestellt wurde. Themen verbrachten in OCL Gruppen
weniger Zeit, das System zu verstehen. Zusätzlich fanden die Themen auch die Aufgabe einfacher durchzuführen (p-value=0.006 mit
mean(Kurs2)=2.8 und mean(Kurs4)=2).
Merken Sie, dass solche Resultate nicht in den Fragebögen des
Kurs 2 beobachtet wurden.
Figure 13: Beschreibung von Statistik des Kurses 4(M)
Figure 14: ANOVA Tabelle-Kurs 4(M)
• Diskussion von Resultate
298
Figure 15: Graph der Mittelwerte von Kurs 4(M)
Bevor man sich auf die Resultate konzentriert, lasst man sich die
Veränderung der Teilnehmer über die Kurse besprechen. Da der
Fall in vielen kontrollierten Experimenten existiert, haben nicht alle
Kursteilnehmer an allen Kurse teilgenommen. Für jede abhängige
Variable beobachtet man einen Verlust in der Themen.
Die Themen sind über Methode und Fähigkeit sehr ähnlich (wie
in den beschreibenden Statistiktabellen gezeigt) und es gibt folglich
keinen Grund, die Resultate beeinflusst wurden. Eine allgemeine
Tendenz war über allen Kurse und Aufgaben, dass es einen starken
Lerneffekt zwischen der Kursteilnehmern zuerst an der Aufgabe oder
zweiten an der Aufgabe versucht. Das heisst, dass die Kursteilnehmern
ausgebildet haben, wenn sie OCL in den grösseren und komplizierteren
UML-Modellen verwendeten. Sobald in Kurs 4 das Lernen durchführte,
gibt es offenbar einen positiven Effekt von OCL auf die Fähigkeiten der
Kursteilnehmern. ANOVA erscheinen Resultate, dass der Effekt von
OCL zu der Fähigkeiten der Kursteilnehmern zwar für die Wartung
einfach additiv ist, konnte eine grössere Probe einen bedeutenden
Interaktion Effekt zur Verfügung gestellt haben.
Es schlägt weiter vor, dass der Effekte von OCL statistisch und
praktisch bedeutend sind: Er erklärt zwischen 13 Prozent und 27
Prozent der Abweichung (E2). Er erhöht sich die richtige Antworten
um mehr als 40 Prozent und die Vollständigkeit um 13 Prozent und 122
Prozent für die Kursteilnehmer der hohen und niedrigen Fähigkeiten.
Diese Resultate werden durch unsere übersichtliche Daten gestützt
und bringen Einblick für die Auswirkung von OCL. Die Resultate
dieser Studie zeigen offenbar, dass OCL als Begrenzung Sprache ist,
die zu UML ergänzend ist. Wenn man die Änderung solcher Modelle
erleichtert, muss die Interaktion des Modellierens von der Fähigkeiten
mit diesem Effekt weiter studiert werden und verstanden werden.
299
Dieses Training war für die Kursteilnehmern bedeutend, die an
diesem Experiment teilnahmen. Obwohl sie nicht die Erfahrung vieler
Software-Fachleute haben, ist es unsere Beobachtung, die ihr UML und
OCL Training viel vollständiger als die meisten Software Engineers in
der Industrie ist. Unsere Resultate vorschlagen, dass Leute nur vom
Verwenden des exakteres Modellierens durch den Gebrauch von OCL
einmal profitieren. Wenn sie umfangreicheres Trainingin empfangen,
haben sie in UML und in OCL typisch Trend von Praxis.
3.1
Ergebniszusammenfassung
Dieses Experiment forscht einen wichtigen methodologischen Aspekt von
der vereinheitlichten modellierenden Sprache (UML) [2] für OO Analyse
und Design nach: Ob die Gegenstand-Begrenzung Sprache (OCL) [1] das
ein Teil des UML Standards ist. Im spezifischen Kontext von UML ist diese
Frage über das erforderliche Niveau der Förmlichkeit und Präzision in der
Software-Entwicklung [13, 14] sehr viel entsprechend.
Um diese Frage nachzuforschen führt man ein Experiment mit die
Technikkursteilnehmern von Software/Computer durch, die ein sehr vollständiges Training in UML und in OCL empfangen. Dieses Experiment
betrachtete die Auswirkung des Verwendens von OCL auf zwei Variablen:
(1) führen die Antwort der Frage über die basierende Logik des Systems und
(2) analysiert eine Auswirkung der Änderungen und führt mit dem UML
Modell durch. Das Entwurf des Experimentes wurde definiert, um Verwirren
zu verhindern. Es ist wichtig, dass interne Gültigkeit unseres kontrollierten
Experimentes sicherstellen kann, indem man die Tendenzen sicherstellte, die
man an OCL liegt.
Die Resultate zeigen, dass OCL eine positive Auswirkung auf die zwei
oben erwähnten Variablen hat. Diese Auswirkung ist statistisch und
praktisch bedeutend. Die Tatsache sieht man, dass ein Effekt eine Sache ist,
aber interessanter ist, dass Effekt sehr gross sein kann. Dieses schlägt dann
vor, dass der Kosten-Nutzen-Aspekt des Verwendens von OCL wichtig ist.
Jedoch wurden die oben genannten Resultate nur beobachtet, dass
zweite mal als Kursteilnehmern die Aufgaben durchführten. Das heißt, dass
man einen Lerneffekt beobachtet, während des Laufenes des Experimentes
lassen, verteilt mann durch die Daten der übersichtliche Fragebogen nach
jedem Kurs. Dieses sollte tatsächlich erwartet werden, obwohl die Kursteil300
References
nehmern ein eingehendes UML und OCL Training hatten. Sie hatten keine
viele Erfahrungen mit Dokumenten des Niveaus der Kompliziertheit in den
UML Modellen, die im Experiment benutzt wurden. Sie hatten auch wenig
Erfahrung in Bezug auf die Besonderen der Aufgaben durchzuführen.
In der Folgerung zeigten die Resultate unseres Experimentes, dass
OCL Potential für die Fähigkeit der Leute auf UML-Modelle kontrolliert
und ändert. Aber mann braucht erforderliche Training und Erfahrung. Von
einer praktischen Perspektive bedeutet dieses, dass es unwahrscheinlich ist,
dass Leute vom Verwenden des OCL in UML Modellen profitieren, denn sie
korrektes Training haben.
Eine Reproduktion dieses Experimentes ist durchgeführt worden und
Daten werden z.Z. analysiert. In diesem Experiment forschtet man nur
einen teilweisen Aspekt der Auswirkung von OCL auf UML-gegründete
Software-Entwicklung nach. Weitere Studien sind notwendig, zum Beispiel,
dass die Auswirkung des Verwendens von OCL auf die Qualität der
Basissprache(source code quality) nachforschen, und in den folgenden
Entwicklung Phasen stützt.
References
[1] L. Mandel und M. C. Cengarle: On the expressive power of the object constraint language OCL. Forschungsinstitut für angewandte Softwaretechnologie (FAST e.V.), http://www.fast.de, 1999
[2] J. Warmer und A. Kleppe: The Object Constraint Language: Precise
Modeling with UML. Addison-Wesley, 1999.
[3] H. Hussmann:Lehrmaterialien zur Vorlesung Formale Spezi
kation von Softwaresystemen
[4] Denger, C.; Paech, B.; Benz, S.: Guidelines - Creating Use Cases for
Embedded Systems. IESE Technical Report, 2003.
301
[5] Briand, L.; Labiche, Y.; Yan, H.; Penta, M.: A Controlled Experiment
on the Impact of the Object Constraint Language in UML-based Maintenance. In Proceedings of the 20th IEEE International Conference on
Software Maintenance (ICSM’04). IEEE Press, 2004.
[6] Silva, L.F.S.; Travassos, G.H.: An empirical study of a Qualitative Systematic Approach to Requirements Analysis (QSARA). International
Symposium on Empirical Software Engineering. ISESE ’04. IEEEPress,
2004.
[7] Paper,K.Aberer,P.Cudr -Mauroux,A.Datta,et al.,”P-Grid:A Self- organizing Structured P2P System”,Lausanne,2003
[8] C. Larman, Applying UML and Patterns - An Introduction to ObjectOriented Analysis and Design and the Unified Process, Prentice Hall,
2002.
[9] L. C. Briand, Y. Labiche, H.-D. Yan and M. Di Penta, ”A Controlled
Experiment on the Impact of the Object Constraint Language in UMLBased Development,” Carleton University, Technical Report SCE-03-22,
www.sce.carleton.ca/Squall, 2003.
[10] J. L. Devore and N. Farnum, Applied Statistics for Engineers and Scientists, Duxbury, 1999.
[11] Kitchenham, B.: Evaluating Software Engineering Methods and Tools Part : Quantitative Case Study Methodology; ACM SIGSOFT Software
Engineering Notes, 23(1), pp. 24-26; 1998.
[12] Thelin Thomas, Runeson, Per; Wohlin, Claes: An Experimental Comparison of Usage-Based and Checklist-Based Reading; IEEE Transactions on Software Engineering, Vol 29, No. 8; 2003.
[13] S. L. Pfleeger and L. Hatton, ”Investigating the Influence of Formal
Methods,” Computer, vol. 30 (2), pp. 33-43, 1997.
[14] A. E. K. Sobel and M. R. Clarkson, ”Formal Methods Application: An
Empirical Tale of Software Development,” IEEE TSE, 28 (3), pp. 308320, 2002.
[15] S. L. Pfleeger, ”Understanding and improving technology transfer in software engineering,” Journal of Systems and Software, 47 (2-3), pp. 111124, 1999.
302
Effekte des Pair Programming
Lars Mahnkopf
1
Einführung
In den letzten Jahren wurden immer mehr alternative Softwareentwicklungsmethoden erarbeitet, welche versuchen die teilweise starren, traditionellen Konzepte zu ersetzen oder zu ergänzen. Pair Programming ist hierbei als ein Bestandteil des Extreme Programming zu verstehen, welches
wiederum in die Klasse der agilen Softwareentwicklungsmethoden einzuordnen ist. Diesen Methoden ist gemein, daß sie sich durch wenige, flexible
Regeln auszeichnen und mit wenig bürokratischem Aufwand daherkommen.
Die vorliegende Arbeit versucht einen kleinen Einblick in die bisherigen Studien zu geben, die Pair Programming unter verschiedenen Aspekten und
Bedingungen untersucht haben und dabei versuchen, die Effektivität dieser
Methode einzuschätzen.
1.1
Pair Programming
Unter Pair Programming versteht man das gemeinsame Programmieren
zweier Entwickler an einem Rechner. Einer der Entwickler übernimmt dabei
die Funktion des ”Handelnden” wobei der Andere als Kontrollperson fungiert
und diese Rollen in regelmäßigen Zeitabständen getauscht werden. Diese
Methode beschrä-nkt sich nicht nur auf die Implementierung, sondern kann
auch beim Softwaredesign und der Entwicklung von Algorithmen zum Einsatz kommen.
2
Empirische Studien
Um einen Überblick der bisherigen Forschungsergebnisse zu erhalten, wurde
eine Auswahl an Studien untersucht, die allerdings nicht immer direkt
miteinander verglichen werden können, da sowohl die Versuchsumgebung als
auch die zu untersuchenden Hypothesen sich voneinander unterscheiden. Ein
Großteil der Studien wurde an Universitäten durchgeführt, nur zwei wurden
mit Hilfe professioneller Programmierer erstellt. Außerdem unterschieden
sich die zu lösenden Aufgaben in Aufwand und Schwierigkeitsgrad. Hierzu
ist zu sagen, daß diese Unterschiede eher als Bereicherung zu verstehen sind,
da es so möglich ist ein realistischeres Bild über die Effekte des Pair Programming zu erhalten.
2.1
Untersuchungsrahmen
Als erstes sollen nun die einzelnen Studien in ihrem Aufbau beschrieben werden. Hierbei interessiert uns insbesondere die Anzahl der Versuchspersonen,
306
2 Empirische Studien
ihr Beruf, wie die erstellten Programme getestet wurden, die Dauer des Versuches, in welcher Umgebung der Versuch durchgeführt wurde und welche
Komplexität die gestellten Aufgaben besaßen. Der Umfang der einzelnen
Beschreibung weicht stark voneinander ab und entspricht dem Detailreichtum der jeweiligen Arbeiten.
2.1.1
The Benefits of Collaboration for Student Programmers
J. D. Wilson , N. Hoskin und J. T. Nosek untersuchten 34 Studenten einer
amerikanischen Universität, wobei 14 von ihnen einzeln und die anderen 20
in Paaren arbeiten sollten. Hierbei ist vielleicht noch von Interesse, daß
alle durch einen Schein motiviert werden sollten an dem Experiment lebhaft teilzunehmen. Allerdings wurde beim Nichtlösen der Aufgabe keine
schlechtere Note vergeben. Die Paare wurden zufällig zusammengestellt und
beide Gruppen hatten dann 60 Minuten Zeit, um Kontrollfunktionen für
eine Verkehrssteuerung zu implementieren. Diese Aufgabe wird vom Autor
als einfach genug beschrieben, um von Programmieranfängern gelöst werden
zu können. Den Paaren war selbstverständlich erlaubt sich über das Problem auszutauschen, wohingegen die Einzelpersonen gezwungen waren untereinander nicht zu kommunizieren. Nach Vorlage der Ergebnisse, wurden noch
zwei Fragen qualitativer Natur an die Studenten gerichtet. Zur anschließenden Auswertung ist zu sagen, daß diese von zwei Studenten vorgenommen
wurde, die nicht wußten von welcher Gruppe die jeweilige Lösung stammte.
2.1.2
The Case of Collaborative Programming
Noseks zweites Experiment zielte darauf ab, die von ihm gewonnenen
Erkenntnisse durch ein geeignetes Experiment in einer realistischeren und
ökonomisch orientierteren Umgebung zu überprüfen. Hierzu wurden 15 Programmierer einer Software-Firma mit einem Problem konfrontiert, das bis
dato nicht zu ihrem Arbeitsbereich zählte. Es sollte ein Skript erstellt werden,
das die Konsistenz einer Datenbank überprüft und bei gefundenen Fehlern
entsprechende Meldungen ausgibt. Im Falle einer fehlerfreien Datenbank,
sollte dies ebenfalls als Nachricht ausgegeben werden. Normalerweise wurden solche Probleme außerhalb der Firma gelöst, da sie zu kritisch schienen
und über das Know-How der eigenen Programmierer hinausgingen. Zur Lösung hatten die Probanden 45 Minuten Zeit und als Programmierumgebung
wurden die ihnen bekannten SPARCs verwendet. Die Zeit wurde mit einer
Stoppuhr gemessen und nach Abgabe, wurden wieder dieselben qualitativen
Fragen wie in dem Experiment mit den Studenten gestellt.
307
2.1.3
Pair-Programming Effects on Developers Productivity
Diese von vier Studenten an der Universität von Tartu in Estland entwickelte
Arbeit wurde mit Hilfe von anfänglich 110 Studenten des Sommersemesters
2002 erstellt. Die Studenten waren größtenteils im ersten Jahr und hatten sowohl im Programmieren wie auch in Sachen Teamarbeit wenig bis gar
keine Erfahrung, bis auf einen einsemestrigen Javakurs. Ein Hauptunterschied zwischen den bisherigen Studien bestand darin, daß hier nicht Paare
mit Einzelpersonen, sondern Paare mit anderen Paaren verglichen wurden,
wobei die eine Gruppe von Paaren mit Hilfe von traditionellem Teamwork
und die Andere auf Basis des Pair-Programming arbeiten sollte. Hierzu wurden die Studenten in 2 gleichgroße Gruppen aufgeteilt, die Paare wurden in
diesen Gruppen gebildet und ihnen wurden eine Aufgabe gestellt, für deren
Lösung sie 2 Arbeitssitzungen Zeit hatten. Danach wurden innerhalb der
beiden Gruppen die Paare neu zusammengesetzt und die Gruppe, die vorher
Pair-Programming betrieben hatte, löste die neugestellte Aufgabe nun mit
Hilfe traditioneller Gruppenarbeitskonzepte und umgekehrt. Die zu lösenden
Aufgaben bestanden darin, einen ”Schiedsrichter” für ein Strategiespiel zwischen zwei Spielern auf einem vordefinierten CORBA-System zu implementieren. In der ersten Phase des Experiments wurde das Regelwerk entwickelt
und in der zweiten Phase dann das Spieleprotokoll implementiert. Mit Hilfe
eines automatischen Testprogramms, das von den Leitern des Experiments
vorher entworfen worden war, wurden dann die eingereichten Lösungen auf
Richtigkeit überprüft. Dieses simulierte 2 Spieler, die anhand einer gegebenen
Datenbank erlaubte und unerlaubte Spielzüge ausführten, wobei die Ergebnisse zur Auswertung gespeichert wurden. Bei der Untersuchung der qualitativen Bereiche des Experiments, wurde mit Hilfe eines Persönlichkeitstests
NEO PI versucht, eine Antwort auf 3 von den Autoren gestellte Fragen zu
geben. Auf diese Fragen wird später im Detail bei der Analyse der qualitativen Aspekte eingegangen.
2.1.4
Strengthening the Case for Pair Programming
Das Experiment in dieser Studie wurde 1999 von Laurie Williams, R. R.
Kessler, Ward Cunnigham und Ron Jeffries an der Universität von Utah
mit 41 höhersem-estrigen Studenten durchgeführt, die alle schon fortgeschrittenere Kenntnisse im Programmieren und Kontakte zur Industrie besaßen.
13 Studenten bildeten die Kontrollgruppe aus Einzelpersonen, während der
Rest sich zu Paaren formierte, die die gestellten Aufgaben mit Hilfe der
Pair Programming Methode lösen sollten. Um die Arbeitsbelastung auszugleichen, bekamen die Paare zusätzlich Aufgaben gestellt. Die Arbeitszeit
308
wurde in diesem Fall über ein webbasiertes Tool festgehalten und das Testen
wurde auch hier automatisiert durchgeführt. Auch wurden die Studenten
über Auswirkungen, die ihres Erachtens die Methode hatte, und ihre Einstellung zum Pair Programming befragt. Allerdings geht aus der Studie nicht
hervor, in welcher Art und Weise dies geschah. Auch gehen die Autoren nicht
näher auf die Art der Aufgaben und die Umgebung ein, in der diese gelöst
wurden.
2.1.5
Experimental Evaluation of Pair Programming
Im Wintersemester 1999/2000 führten 2 Studenten der Universität von Posen
4 Versuche mit 21 Studenten durch, um die Effizienz des Pair Programming
zu beweisen. Im Gegensatz zu den meisten anderen Studien, wurden hier
nicht 2 sondern 3 Gruppen gebildet, wobei eine Gruppe mit Hilfe des Pair
Programming arbeitete, wie es im Zusammenhang mit Extreme Programming verstanden wird, die zweite nach der Methode des Personal Software
Process(PSP) und die letzte auch nach den Prinzipen des Extreme Programming, allerdings ohne Hinzunahme des Pair Programming. Bei der Zusammensetzung der Gruppen wurde darauf geachtet diese möglichst ausgeglichen
zu halten, was man mit dem Notendurchschnitt probierte. Alle Studenten
befanden sich im vierten Jahr ihres Studiums und hatten schon vorher an
Experimenten dieser Art teilgenommen. Daher war ihnen bewußt, daß nicht
ihr Können, sondern die Effizienz der einzelnen Methoden im Vordergrund
stand. Die Zeit sowie die auftretenden Fehler sollten in entsprechenden Logs
gespeichert werden, wobei nur innerhalb der Universität unter Aufsicht von
einem der beiden Autoren an den Programmen gearbeitet wurde. Bei den
zu lösenden Aufgaben handelte es sich um 4 Aufgaben, die zwischen 150-400
Zeilen an Code umfassten. Den Probanden war es freigestellt, ob sie mit
Pascal, C oder C++ arbeiten wollten, allerdings entschieden sich alle für die
letzteren beiden. Zuerst sollte ein Programm geschrieben werden, das den
Mittelwert und die Standardabweichung von n natürlichen Zahlen berechnet. Danach sollten die linearen Regressionsparameter berechnet werden,
das Dritte hatte die Aufgabe, die wirklichen Zeilen an Code zu bestimmen
(ohne leere Zeilen und Kommentare) und das letzte Programm diente dem
Zählen der Codezeilen und der Anzahl an Zeilen sowie der Anzahl an Methoden innerhalb eines Objekts. Nach Einreichen der Lösungen, wurden diese
von den Leitern mit Fehlern versehen, die dann von den Studenten gefunden werden sollten. Die dafür benötigte Zeit wurde wiederum festgehalten
und diente dazu herauszufinden, ob beide Studenten der Pair Programming
Gruppen dieselben Kenntnisse von ihrem Programm hatten.
309
2.1.6
Are Reviews an Alternative to Pair Programming?
Ein weiteres Experiment zu diesem Thema wurde im Sommersemester 2002
an der Universität von Karlsruhe von Matthias M. Müller während eines
Extreme Programming Kurses durchgeführt. Die Versuchsteilnehmer waren
im Durchschnitt im vierten Jahr ihres Studiums und hatten 6 Jahre Programmiererfahrung mit 50 bis 250000 Zeilen an selbstgeschriebenem Code
(durchschnittlich 2000 Zeilen an Code). Auch hier wurde Pair Programming
nicht mit traditionellen Entwicklungsmethoden verglichen, sondern einer prüfungsintensiven Methode gegenübergestellt. Die zu lösenden Aufgaben bestanden einerseits darin, die Nullstellen eines Polynoms dritten Grades zu
bestimmen, sowie eine Lösung für ein Shuffle Puzzle zu finden, sofern diese
existierte.
2.1.7
An Empirical Study about the Feelgood Factor in Pair
Programming
Matthias M. Müller, einer der Authoren des Papers ”Are Reviews an Alternative to Pair Programming”, versucht anhand desselben Experiments,
das dieser Arbeit zugrunde lag und eines weiteren Gleichgearteten, die qualitativen Aspekte des Pair Programming näher zu untersuchen. Außerdem
versuchen die Authoren die Frage zu beantworten, inwieweit die Programmiererfahrungen der Versuchsteilnehmer die Zeit zum Lösen der Aufgaben
beeinflußten. Zu diesem Zweck wurden die Probanden vor und nach dem Experiment gebeten, zwei kleine Fragebögen auszufüllen. Diese Fragen wurden
auch in der vorausgehenden Arbeit bei der Auswertung einbezogen, finden
in dieser Studie aber mehr Berücksichtigung. Wohingegen die erste Arbeit
mehr darauf abzielte, die generelle Effektivität der Pair Programming Methode zu untersuchen, wird hier der Versuch unternommen, einen Faktor für
die Unterschiede zwischen den einzelnen Paaren zu benennen.
2.1.8
Zusammenfassung
Zum Ende dieses Kapitels möchte ich die wichtigsten Kenndaten der Experimente nochmals tabellarisch zusammenfassen, wobei die Arbeit über den
Feelgood Factor nicht mehr separat aufgelistet wurde, da sie, wie bereits erwähnt, auf demselben Experiment beruht, wie die Studie ”Are Reviews an
Alternative to Pair Programming”.
310
Studie
[WiHoNo93]
[Nosek98]
[PuSeSa03]
[WiKeCuJe00]
[NawWoj01]
[Müller04]
Anzahl
34
15
110
41
21
20
Beruf
Studenten
Professionelle
Studenten
Studenten
Studenten
Studenten
Vergleich
PP vs EP
PP vs EP
PP vs 2EP
PP vs EP
PPvsXP1vsPSP
PP vs EP(R)
Umgebung
Labor
Büro
Labor
Labor
Labor
Labor
Umfang
60 Min
45 Min
2 Aufgaben
k.A.
4 Aufgaben
2 Aufgaben
Testmethode
Person
Person
auto
auto
k.A.
auto
PP=PaarProgrammierer,EP=Einzelprogrammierung
XP1=Einzelprogrammierung nach Extreme Programming Prinzipien
(R)=Programmierung mit Reviews PSP=Methode des Personal Software Process
2EP=2 Einzelprogrammierer mit traditionellen Teamwork
Table 1: Experimente im Überblick
2.2
Forschungsinhalte
Die meisten Arbeiten zu diesem Thema gehen sowohl auf die qualitativen
Effekte, als auch auf die quantitativen Effekte ein, wobei allerdings dem
quantitativen Aspekt oftmals mehr Aufmerksamkeit gewidmet wurde, was
sich aufgrund der einfacheren Auswertung und des ökonomischen Interesses
leicht erklären läßt. Im Folgenden sollen diese Effekte im Detail benannt
werden.
2.2.1
Qualitative Effekte
Zu den häufigst genannten qualitativen Vorteilen des Pair Programming zählt
wohl der ”Spaßfaktor”. Dies wird in jeder Studie deutlich, die diesen Aspekt
untersuchte. Die Probanden scheinen ein Gefühl von Sicherheit zu bekommen, wenn jemand neben ihnen sitzt, der mitdenkt und sie sich so mit dem
Problem nicht alleine gelassen fühlen. Ein weiterer Aspekt, der bei der Befragung der Probanden durchschimmerte, war der aufkommende Leistungsdruck durch die Präsenz eines anderen, der sich wohl darauf zurückführen
läßt, daß die Personen sich nicht blamieren und/oder ihren Partner nicht im
Stich lassen wollten (siehe [WiHoNo93]). Allerdings könnte sich genau dieser
Aspekt bei längeren Studien zur Bremse für diese Methode herausstellen, da
die anfängliche Euphorie dann verflogen sein könnte und die Programmierer
sich nicht mehr von ihrem Partner unter Druck setzen lassen oder die Zeit
durch Small Talk verschwenden. Ein anderer Aspekt ist das Vertrauen in die
entwickelte Löung, welches im Allgemeinen höher war als bei den Kontrollgruppen, die ohne Pair Programming gearbeitet haben. J. T. Nosek befragt
in seinen beiden Studien die Versuchspersonen direkt nach ihrem Vertrauen
in die erstellte Lösung und den Grad an Freude, den sie bei der Arbeit hatten. Sowohl in seiner Studie mit professionellen Programmierern als auch in
der mit Studenten, kommt er zu den gleichen Ergebnissen, was die Befriedigung durch die Arbeit betrifft. Nachfolgend seien kurz die Ergebnisse dieser
beiden Untersuchungen tabellarisch aufgelistet (siehe Tabellen 2 und 3). Zur
311
Interpretation ist zu sagen, daß die Werte zwischen 1 und 7 liegen, wobei 1
für ”sehr niedrig” und 7 für ”sehr hoch” steht.
Variable Einzelperson Paar
Vertrauen
4.43
6.2
Freude
4.93
6.0
Table 2: Experiment mit Studenten
In diesem Zusammenhang sei die Korrelation zwischen den Werten ”Freude”
Variable Einzelperson Paar
Vertrauen
3.8
6.5
Freude
4.0
6.6
Table 3: Experiment mit professionellen Programmierern
bzw. ”Vertrauen” und der Gesamtpunktzahl, sowohl bei den Kontrollgruppen
wie auch bei den Versuchsgruppen erwähnt, also der Verbindung zwischen
den qualitativen und quantitativen Effekten.Hier sieht Nosek bei seinem Experiment eine deutliche Abhängigkeit zwischen diesen Werten, was anhand
der Tabelle nachvollzogen werden kann.
Note
Vertrauen
Freude
0.5195
0.4253
0.4587
0.6311
0.5746
0.6027
0.5062
0.2950
0.3853
0.3735
0.6662
Lesbarkeit Funktionalität Gesamtwert Note
Table 4: Korrelationswerte für die Kontrollgruppen
Auch M. M. Müller befragte in seiner Studie die Probanden danach,
wie sehr ihnen das Pair Programming gefiel. Auf einer Skala von 1 bis
5 , wobei 1 für sehr schlecht steht, gab es keine Wertung unter 4. Somit
wird auch hier diese Methode der Programmierung für die Meisten als die
Angenehmere betrachtet. Neben dieser Frage wurden die Teilnehmer des
Experiments auch noch nach ihren Einschätzungen über die Effizienz des
Programmierens mit Überprüfung und in Paaren, sowohl separat als auch
im direkten Vergleich, befragt. Daß die meisten Versuchsteilnehmer der
Paarprogrammierung mehr Effizienz zusprachen, sowohl bei der Einzelbewertung wie auch im Vergleich, läßt wieder auf ein höheres Vertrauen in die
312
Note
Vertrauen
Freude
0.1527
0.2500
0.2648
0.0000
0.6402
0.6186
0.2020
0.1050
0.4140
0.4152
0.3522
Lesbarkeit Funktionalität Gesamtwert Note
Table 5: Korrelationswerte für die Versuchsgruppen
Programme schließen, die mit dieser Methode erstellt wurden (siehe Bild 1).
Ebenfalls von Müller stammt eine Arbeit, die auf zwei vorausgegangenen
Figure 1: Ergebnisse der Befragungen nach dem Versuch
Versuchen (einer davon wurde mit [Müller04] vorgestellt) basiert und unter
anderem versucht, eine Verbindung zwischen den qualitativen und quantitativen Faktoren herzustellen. Hierzu wird der Durchschnitt für jedes Paar aus
den Werten für die individuelle Freude beim Pair Programming gebildet und
mit der Zeit verglichen, die diese Paare zum Lösen der jeweiligen Aufgabe
benötigten (siehe Bild 2). Bis auf wenige Ausreisser, scheinen diese beiden
Figure 2: Spaßfaktor pro Paar
Werte zu korrelieren. Eine Aussage, die durch einen p-Wert von 0.01 beim
Spearman Test unterstützt wird. Diese Korrelation, sofern sie wirklich existiert, gibt allerdings nicht Aufschluß darüber, welcher Wert von welchem
abhängig ist, ob also ein höherer Spasßfaktor zu den besseren Zeiten führt
oder ein besseres Ergebnis diesen Faktor beeinflußt.
313
2.2.2
Quantitative Effekte
Bei den quantitativen Effekten, läßt sich insbesondere die reduzierte Entwicklungszeit und die geringere Anzahl von Fehlern nennen. Um diese Effekte
detailiert darzustellen, werden nun einige Tabellen und Grafiken aus den
jeweiligen Studien vorgestellt.
Fehlerhäufigkeit: Die Arbeitsgruppe um L. Williams verzeichnete bei ihren
automatisch durchgeführten Tests einen deutlichen Unterschied zwischen
Paaren und Programmierern, die einzeln arbeiteten, der im Maximum bei
16,7 % mehr bestandenen Tests lag (siehe auch Tabelle 6). Im Gegensatz
Programm
Programm
Programm
Programm
1
2
3
4
Einzelperson Paar
73.4
86.4
78.1
88.6
70.4
87.1
78.1
94.4
Table 6: Prozentangaben zu den bestandenen Tests
dazu, wurden bei Noseks Arbeiten nicht die prozentual bestandenen Tests
verglichen, sondern zwei Variablen eingeführt, die zum Vergleich genutzt
wurden. Die eine sollte etwas über die generelle Lesbarkeit der Programme
aussagen, also inwieweit das Implementierte anhand der Kommentare und
der Struktur nachvollzogen werden konnte. Die Werte hierfür liegen im Rahmen von null bis zwei mit null als Bewertung für ein nicht nachvollziehbares
Programm. Die Variable ”Funktionalität” wiederum gibt Auskunft darüber,
in welchem Maße die Lösung mit der Aufgabenstellung übereinstimmte und
bewegt sich zwischen null und sechs, wobei null einer nicht gegebenen Funktionalität enspricht. Die Variable ”Gesamtwert” ergibt sich aus der Aufaddierung der anderen beiden Werte und dient dem direkten Vergleich. Die
Tabellen 7 und 8 geben die Mittelwerte dieser drei Variablen für die jeweiligen Experimente an (die Werte in den Klammern stehen für die Standardabweichungen).
Auch diese beiden Experimente sprechen eine deutliche Sprache in Bezug
auf die Fehlerrate des Pair Programming. Bei den Studenten erreichen die
Einzelpersonen gerade 54% des maximalen Gesamtwertes, wohingegen die
Paare im Durchschnitt auf 74.3% der Punkte kommen. Bei den professionellen Programmierern ergibt sich ein ähnliches Bild nur auf höherem
Niveau. Es werden bei den Einzelpersonen 74% und bei den Paaren 95%
314
Variable
Einzelperson
Paar
Lesbarkeit
1.2857 (0.6712) 1.7500 (0.2887)
Funktionalität 3.0357 (2.2055) 4.2000 (1.9285)
Gesamtwert
4.3214 (2.8053) 5.9500 (1.9958)
Table 7: Noseks Experiment mit Studenten
Variable
Einzelperson
Paar
Lesbarkeit
1.40 (0.894) 2.00 (0.000)
Funktionalität 4.20 (1.788) 5.60 (0.547)
Gesamtwert
5.60 (2.607) 7.60 (0.547)
Table 8: Noseks Experiment mit professionellen Programmierern
der Gesamtpunkte erreicht. Somit liegt die Differenz bei beiden Studien
ungefähr bei 20%. Anhand der Werte für die Standardabweichung, läßt sich
auch erschließen, daß die Programme, die mit Hilfe des Pair Programming
erstellt wurden, vorhersagbarer sind als bei den Einzelprogrammierern. Eine
mögliche Erklärung hierfür mag sein, daß die Paarbildung schon zu einer
gewissen Nivellierung führt, so daß die Ergebnisse dichter beisammen liegen.
Bei den bisherigen Studien zeichnet sich der Trend ab, daß sich Pair Programming im direkten Vergleich zu Einzelprogrammierern durch eine geringere Fehleranzahl auszeichnet. Bei [WiKeCuJe00] liegen die Unterschiede
zwischen 10.5% und 16.7% mehr bestandenen Tests und bei den Studien von
Nosek ( [Nosek98], [WiHoNo93]) spiegelt die Variable ”Funktionalität” diese
Unterschiede wieder.Bei der Auswertung der Daten wird zunächst lediglich
auf den Gesamtwert eingegangen, da die Variable ”Lesbarkeit”, die in diesen
Wert miteinfließt, zwar nicht direkt über die Fehler Aufschluß gibt, jedoch
mit einer hohen Lesbarkeit Fehler schneller gefunden werden können und sie
somit indirekt die Anzahl von Fehlern reduziert.
Da die bisherigen Vergleiche nicht ganz ”fair” sind, da bei ihnen außer Acht
gelassen wird, daß die geringere Fehleranzahl auch mit doppelt sovielen Programmierern und damit doppelt so hohen Personalkosten einhergeht, wollen
wir uns nun den Studien widmen, die die Paare mit 2 Programmierern
oder zusätzlich angewandten Prinzipien vergleichen. Die erste Studie hierzu
sei [PuSeSa03]. Sie stellt den Paaren 2 Programmierer mit traditioneller Teamarbeit gegenüber. Da bei diesem Versuch die Zeit konstant gehalten wurde
(die Probanden hatten jeweils 2 Sitzungen für die Lösung eines der beiden
Probleme Zeit), wurde nur die Anzahl der bestandenen Tests pro Sitzung verglichen. Nachfolgend seien kurz die Ergebnisse der Studie tabellarisch aufgelistet. Anfänglich sind die Paare, die nach dem Pair Programming Prinzip
315
PP
NP
PP
Wert2
NP
Wert1
Phase1
Phase2
Sitzung1 Sitzung2 Sitzung1 Sitzung2
43.5%
73.9%
18.0%
62.5%
26.3%
78.9%
0.0%
47.1%
14.9%
66.1%
2.2%
24.7%
8.0%
72.7%
0.0%
25.0%
Table 9: Paar Programmierer vs 2 Einzelprogrammierer
arbeiten, wie es scheint im Vorteil. Sie bestanden nach Ende der ersten
Sitzung 1.9 mal mehr Tests als die Paare mit traditionellem Teamwork (kurz
Teams) und 1.7 mal mehr Paare schafften es, überhaupt einen Test positiv
zu durchlaufen. Dies läßt sich noch gravierender in der ersten Sitzung der
zweiten Phase feststellen. Hier schaffte es kein Programm der Kontrollgruppe
auch nur einen Test zu bestehen, wohingegen bei 18% der Paare schon mindestens ein Test erfolgreich durchgeführt und im Durchschnitt 2.2% der Tests
bestanden wurden. Mit der zweiten Sitzung setzt allerdings eine Wende ein.
Sowohl in der ersten Phase holen die Teams deutlich auf und überflügeln die
Paare sogar leicht, wie auch in der zweiten Phase bei der Anzahl der durchschnittlich bestandenen Testfälle. Nur bei der Anzahl der Gruppen, die überhaupt ein testfähiges Programm ablieferten, sind die Paare noch im Vorteil.
Die anfängliche schwächere Leistung der Teams läßt sich wohl damit erklären,
daß sie anfänglich mehr Zeit investieren mußten, was sich aber anscheinend
nach dieser Planungsphase zu rentieren scheint. Es ist nicht auszuschließen,
daß sich bei einem so hohen Grad an Leistungszuwachs, die Teams bei längeren Programmen noch deutlicher absetzen würden. Dieses Experiment ist
daher von großem Interesse, da es aufgrund dessen, daß die gleiche Anzahl
von Programmierern in den Kontrollgruppen verwendet wurde, einen direkten Vergleich ermöglicht.
Allerdings gibt es auch die Möglichkeit, anstatt Paare mit Paaren zu vergleichen, die Einzelprogrammierer mit zusätzlichen Methoden auszustatten.
Dieser Ansatz wird in der Studie ”Are Reviews an Alternative to Pair Programming?” verfolgt. Hier sollten die Einzelprogrammierer mit Hilfe einer
Überprüfung arbeiten. Die Methode sah vor, daß der Programmierer seine
Implementierung bis dahin nicht kompilierte, sondern abwarten sollte, bis
er die Liste mit Fehlern zurückerhielt. Sobald dies geschah, stand es dem
Programmierer frei selbst zu testen und weitere Fehler zu suchen. Die
Idee hierbei ist, daß Aufgrund dieser Überprüfung, die Entwickler sich zu
mehr Sorgfalt zwingen und eine zusätzliche Kontrollinstanz vorhanden ist,
die Fehler ausmachen kann. Die interessanten Ergebnisse dieser Studie sind
316
Figure 3: Bestandene Tests in % nach der Implementierungs- und
Akzeptanzphase
vor der Akzeptanzphase zu finden, da nach dieser dennoch alle Programme
mindestens 95% des Akzeptanztests bestanden hatten und selbst beim umfangreicheren Test nicht wirklich nennenswerte Unterschiede festzustellen
waren. Aber selbst nach der reinen Implementierungsphase, ist die durchschnittliche Zuverlässigkeit der Programme, die von den Paaren erstellt wurden, nur geringfügig höher als bei den Einzelentwicklern (die Mediane weisen
sogar fast gar keine Unterschiede auf). Insgesamt ergibt sich hieraus, daß
Paar Programmierer nicht weniger Fehler produzieren als Einzelprogrammierer mit Überprüfung, allerdings kosten sie auch nicht mehr, was sich anhand derselben Studie später zeigen wird. Die letzte Studie gibt in Bezug
auf die Fehlerdichte nur wenig Aufschluß. Der einzige Wert, der in diesem
Zusammenhang genannt wird, ist die Anzahl der erneuten Einreichungen korrigierter Programme. Hierbei erweist sich das Pair Programming als leicht
effizienter wie die Abbildung 4 zeigt.
Reduzierte Entwicklungszeit: Zunächst wird mit denjenigen Studien begonnen, deren Vergleich darauf beruht, daß sie Einzelprogrammierern Paare
gegenüberstellen. In der Studie [WiKeCuJe00] wird behauptet, daß die Paare
bis zu 50% schneller seien (siehe Bild ??). Es wird sogar vermutet, daß
wenn die Einzelprogrammierer die größere Anzahl an Fehlern hätten korrigieren müssen, sie schlechter abgeschnitten hätten. Zu ähnlichen Ergebnisse, wenn auch nicht ganz so optimistisch, kommt Nosek in seiner Studie
mit professionellen Programmierern (siehe [Nosek98]). Während die Kontrollgruppen aus Einzelpersonen im Durchschnitt 42.60 Minuten mit einer
Standardabweichung von 3.361 Minuten brauchen, um das Skript für den
DBCC(database consistency check) zu implementieren, schaffen die Paare
dies in 30.20 Minuten mit einer Standardabweichung von nur 1.923 Minuten,
317
Figure 4: Anzahl der Wiedereinreichungen korrigierter Programme
was ungefähr 71% der Zeit, die die Kontrollgruppe benötigte, entspricht.
Die Studien, die allerdings Paare nicht mit ”einfachen” Einzelprogrammierern vergleichen, kommen in Bezug auf Gesamtzeit zu anderen, für Pair Programming weniger günstigen Ergebnissen. Hier sei als erstes die Studie von
Nawrocki und Wojciechowski genannt ( [NawWoj01]). Zwar brauchen die
Programmierer, die nach dem PSP-Prinzip arbeiten, erkennbar länger, wobei
das letzte Programm hierbei eine Ausnahme bildet, was daran liegen kann,
daß sich der höhere Planungsaufwand erst bei Programmen eines gewissen
Umfangs auszahlt. Dagegen liegt zwischen den Paaren und den Einzelprogrammierern, die nach XP-Prinzipien arbeiten, kaum ein Unterschied. Nur
das letzte Programm fällt hier wieder aus dem Rahmen(siehe Bild 6). Da in
dieser Studie angegeben, wollen wir auch hier die Standardabweichung näher
betrachten. Wieder einmal zeigt sich, daß das Pair Programming die geringsten Abweichungen aufweist (eine Ausnahme bildet das erste Programm).
Die Studie ”Pair-Programming Effect on Developers Productivity” ( [PuSeSa03]) gibt hier keinen direkten Aufschluß über die Reduzierung der Entwicklungszeiten, da hier die Zeiten zur Implementierung der Programme
fest vorgegeben waren, um durch diesen konstanten Wert einen Vergleich der
Fehlerhäufigkeit überhaupt erstmal zu ermöglichen, wie die Autoren meinen.
Allerdings kann man auch argumentieren, daß eine höhere Fehlerrate auch zu
längeren Entwicklungszeiten führt und somit auch indirekt Aufschluß über
die Entwicklungszeiten gibt. Die groben Unterteilungen in der Auswertung
der einzelnen Studien sollen deshalb nicht als strikte logische Trennungen verstanden werden, sondern dienen nur dazu, dieser Arbeit eine gewisse Struktur zu geben. M. M. Müller dagegen verwendet in seiner Arbeit ( [Müller04])
wiederum die Zeit als variable Größe, aber er vergleicht nicht einfach die En318
Figure 5: verkürzte Entwicklungszeiten mit Pair Programming
twicklungszeiten direkt miteinander, sondern die Kosten in Arbeitsminuten.
Auch hieran läßt sich die eigentliche Entwicklungszeit ablesen. Es müssen nur
die Werte der Paare durch zwei geteilt werden. Somit erreichen die Paare ähnlich gute Ergebnisse, wie in der Studie [WiKeCuJe00], also eine Reduzierung
von 40-50% für die gesamte Aufgabe. Interessant ist hierbei allerdings, daß
die Reduzierung für die Implementierungsphase deutlich geringer ausfällt (3040%), wohingegen bei der Akzeptanzphase die Paare im Durchschnitt sogar
mehr als doppelt so schnell sind.
Ein Versuch zur Benennung einer Ursache für die unterschiedliche Arbeitszeit der Paare im Vergleich zueinander, unternahmen Müller und Padberg
in ihrer Arbeit (siehe [MülPad04]), indem sie den Durchschnitt der individuellen Programmiererfahrung pro Paar bildeten. Diese Erfahrungen pro Paar
waren trotz des Versuchs die Paare ausgewogen zu halten (die Person mit
der geringsten Erfahrung bildete mit der Person mit der meisten Erfahrung
eine Gruppe, danach der Zweiterfahrenste mit demjenigen mit der zweitgeringsten Erfahrung usw.) noch relativ weit gestreut (siehe Bild 9).
Allerdings weisen diese auf die Erfahrung der Paare bezogenen Werte keinerlei Korrelation auf , so daß die reine Programmiererfahrung nicht als beeinflussender Faktor für die Entwicklungszeit gesehen werden kann (siehe Bild
10).
2.3
Kritische Analyse
Um aus den gegebenen Daten allgemeingültige Aussagen ableiten zu können,
wollen wir uns als erstes ein Bild über die generelle Verwertbarkeit der InMethoden der empirischen Softwaretechnik
319
Figure 6: Entwicklungszeiten von XP1, XP2 und PSP
Figure 7: Standardabweichungen bei der Entwicklungszeit von XP1, XP2
und PSP
formationen machen, indem wir den Versuchsaufbau und die Durchführung
kritisch beleuchten. Danach werde ich noch kurz auf einige allgemeine Probleme im Zusammenhang mit Experimenten eingehen.
2.3.1
Versuchsaufbau und -durchführung
Allen Experimenten ist zu Eigen, daß sie mit sehr wenigen Versuchsteilnehmern durchgeführt wurden, was die Frage aufwirft, ob die bestätigten
Hypothesen überhaupt eine Allgemeingültigkeit besitzen. Dieses Problem
wird auch von fast alle Autoren erkannt, doch sehen sie sich zum Beispiel
aufgrund des Kostenfaktors oder des Kursumfanges nicht in der Lage daran
etwas zu ändern. Ein anderer Aspekt ist die Art der Versuchsteilnehmer, bei
320
Figure 8: Kosten für Gesamtzeit, Implementierungszeit und Zeit für die
Qualitätssicherung
Figure 9: allgemeine und javabezogene Programmiererfahrungen pro Paar
in Jahren, sowie bisher erstellte LOC in Java
denen es sich außer in einer Studie ( [Nosek98])um Studenten handelt. Die
geringen Erfahrungen werfen hier wieder die Frage auf, ob die gewonnenen
Erkenntnisse auf professionelle Programmierer übertragbar sind. Zwar führte
Nosek genau aus diesem Grund einen entsprechenden Versuch durch, jedoch
kann ein Versuch nicht als Beweis für die vorher vermuteten Ergebnisse gelten. Die Einstellung der Probanden zu dem Experiment ist ebenfalls relevant
und da es sich bei vielen Versuchen um Kurse handelt, die von den Studenten
freiwillig belegt wurden, ist es fraglich ob diese eher positive Grundeinstellung gegenüber dem Thema nicht schon eine Verzerrung darstellt.Auch die
Methode des Testens und Bewertens ist gerade in den Studien von Nosek
kritisch zu betrachten. Hier wird die Fehlerhaftigkeit und Lesbarkeit eines
Programms von zwei Personen bewertet ohne automatische Tests zu verMethoden der empirischen Softwaretechnik
321
Figure 10: Programmiererfahrung und Entwicklungszeit
wenden, was die Frage nach der Genauigkeit und Einheitlichkeit der Werte
aufkommen läßt. Sicherlich ist es gerade bei der Bewertung der Lesbarkeit
nur bedingt möglich, dies zu automatisieren, jedoch wäre es bei dem Messen
der Fehleranzahl möglich. Gerade bei Noseks zweiter Studie tritt ein Problem
auf, da hier sowohl die Zeit wie auch die Funktionalität zu messende Grössen
darstellen. Dabei stellt sich das Problem wie hier von den Programmierern
einheitlich entschieden werden konnte, wann sie fertig sind. Hier erscheinen
die Versuche sinnvoller, die nur eine der beiden Größen untersuchen ( [NawWoj01]) oder zumindest einen Akzeptanztest einführen ( [Müller04], [MülPad04]).
Die Versuchsdauer erscheint oftmals auch viel zu kurz für ein Experiment,
was so starke soziale und psychologische Faktoren beinhaltet. Es ist sicher
nicht schwer sich 45 oder 60 Minuten( [WiHoNo93] und [Nosek98]) oder auch
2-4 Sitzungen ( [PuSeSa03] und [NawWoj01]) zusammenzureißen, allerdings
wäre es doch auch von Interesse zu sehen, wie diese Zusammenarbeit sich mit
der Zeit entwickelt. Hier ist vieles vorstellbar, von dem Verlust des gegenseitigen Ansporns bis hin zur Blockade aufgrund zwischenmenschlicher Differenzen. Die Umgebung ist in fast allen Fällen entweder laborähnlich oder
die von Kursen, was wiederum zu vielerlei Verzerrungen führen kann. Der
Grad an Ablenkung durch die anderen Gruppen und deren Weiterkommen,
die Möglichkeit die Aufgaben außerhalb des eigentlichen Versuchs zu lösen,
stellen hier nur 2 Quellen der Verfälschung dar. Letzteres scheint besonders
in der Studie ”Pair Programming Effekt on Developers Productivity”( [PuSeSa03]) möglich, da hier jede Aufgabe über zwei Sitzungen gelöst wurde. Der
Studie ”Strengthening the Case for Pair-Programming” wiederum mangelt es
viel zu sehr an Informationen über den genauen Versuchsaufbau, was die
ganze Arbeit nicht sehr wissenschaftlich erscheinen läßt.
2.3.2
Allgemeine Verzerrungen bei Experimenten
Die wohl wichtigste Verzerrung stellt der Versuchsleitereffekt dar. Dieser Effekt beschreibt die Tendenz eines Versuchsleiters sein Experiment unbewußt
322
3 Fazit
in eine Richtung zu lenken, die seiner Vorstellung entspricht. Da die meisten Menschen bei der Auseinandersetzung mit einem Thema sich mehr oder
weniger ausgeprägt eine Meinung bilden, besteht die Gefahr, daß diese Meinung Einfluß auf den Experimentverlauf oder die Interpretation der Daten
nimmt. Ohne böswillige Absichten zu unterstellen, könnte man bei einer
Studie den Verdacht haben, daß dies hier vorliegt (siehe [WiKeCuJe00]).
Diese Arbeit weist besonders viele einseitige Zitate über die Vorteile des
Pair-Programming auf und bei näherer Betrachtung der beteiligten Personen
sieht man, daß mindestens eine von ihnen ihren Lebensunterhalt mit dem
Coaching solcher Methoden verdient. Dies entwertet die Ergebnisse nicht
automatisch, stellt aber eine potentielle Verzerrungsquelle dar, da zudem
nicht genug Daten geliefert werden, um diesen Verdacht zu entkräften.
Eine weitere Verzerrung ist unter dem Namen Hawthorne-Effekt bekannt, worunter man die Tendenz des Probanden versteht, sich allein, weil er an einem
Experiment teilnimmt, anders zu verhalten. Diese Möglichkeit sehe ich bei
allen hier vorgestellten Experimenten. Zwar wird in einigen Arbeiten explizit
darauf hingewiesen, daß den Versuchsteilnehmern klar war, daß es nicht um
ihr Können geht, trotzdem kann sich eine Art Prüfungsgefühl einstellen, weil
Fehler gemessen oder Noten vergeben werden. Besonders bei dem Versuch
in der Firmenumgebung scheint mir diese Gefahr gegeben, da die Ergebnisse
hier von der Firmenleitung mit Interesse aufgenommen wurden und dies den
Probanden im Vorfeld sicherlich bewußt war. Man könnte vermuten, daß
hiervon die Paare eher betroffen waren, da sie vielleicht das Gefühl hatten,
daß aufgrund ihrer doppelten Anzahl mehr von ihnen erwartet wird.
3
Fazit
Als Ergebnis dieser Arbeit will ich mich auf die Effekte beschränken, die als
gesichert gelten können. Da es bei allen Probanden eine Vorliebe für das PairProgramming aufgrund des Spaßfaktors zu geben scheint, nenne ich diesen
Motivationsfaktor als einen der wichtigsten Effekte. Ich denke, daß diese
Methode besonders für die Lehre geeignet ist, da so ein Lernen voneinander ermöglicht wird und niemand das Gefühl bekommt, daß er mit einem
Problem alleingelassen wird. Außerdem spielt der Kostenfaktor hierbei keine
Rolle. Für den Einsatz in der Wirtschaft sehe ich weniger Möglichkeiten.
Bei dem Versuch [PuSeSa03] wurde meines Erachtens der beste Vergleich
angestellt, da hier die Kosten für die Kontroll- und Untersuchungsgruppe
dieselben waren. Diese Arbeit zeigt aber, daß Pair Programming nicht effektiver sein muß, sondern sogar überflügelt werden kann, wenn man es nicht
nur mit Einzelprogrammierern vergleicht. Einen Vorteil scheint das Pair ProMethoden der empirischen Softwaretechnik
323
gramming allerdings zu besitzen und dieser liegt in der schnelleren Entwicklung des Designs und erster Lösungen. Auch bei der Fehlersuche scheinen
sich vier Augen bezahlt zu machen. In diesen Entwicklungsphasen macht
Pair-Programming Sinn, allerdings nicht wenn es darum geht, das entwickelte Design zu implementieren, da sich hier schon ähnliche Qualitäten mit
Einzelprogrammierern, die mit Überprüfung arbeiten, erzielen lassen.
References
[Nosek98] J. Nosek. The case of Collaborative Programming. Communication of the ACM,41(3):105-108, März 1998
[WiKeCuJe00] L. Williams, R. Kessler, W. Cunningham und R. Jeffries.
Strengthening the Case for Pair-Programming. IEEE Software, Seiten
19-25, Juli/August 2000
[NawWoj01] J. Nawrocki und A. Wojciechowski. Experimental Evaluation
of Pair Programming. In European Software Control and Metrics (Escom), London, UK, 2001.
[PuSeSa03] S. Heiberg, U. Puus, P. Salumaa und A. Seeba. PairProgramming Effect on Developers Productivity. In XP 2003, number
2675 in LNCS, Seiten 215-224. Springer, 2003.
[Müller04] M. Müller. Are Reviews an Alternative to Pair Programming ?
Journal on Empirical Software Engineering, 9(4):335-351, Dezember
2004.
[WiHoNo93] J. Wilson, N. Hoskin und J. Nosek. The benefits of collaboration for student programmers. In SIGCSE technical symposium on
Computer science education, Seiten 160-164, 1993.
[MülPad04] M. Müller und F. Padberg. An Empirical Study about the Feelgood Factor in Pair Programming.In International Symposium on Software Metrics (Metrics), Chicago, Illinois, USA, September 2004.
324
Effects of Test Driven Development
An Evaluation of Empirical Studies
Philip Ritzkopf
Keywords: Test Driven Development, Test-First
1
Introduction
Test Driven Development (TDD) is known as one of the fundamental practices of the extreme programming (XP) software development process as
described in [1]. The key concept of TDD which seems to be counterintuitive at first is that programmers write low level tests before they write the
production code. This is also referred to as Test-First. The technique which
I will describe in detail in the next subsection relies on a unit testing framework such as JUnit [9] which allows for isolated and automatic tests. Other
than the name suggests TDD is not a pure testing strategy since it drives the
design process by implicitly forcing the programmer to imagine the interface
for the unwritten production code which is used by the current test case.
1.1
The Test Driven Development Workflow
Kent Beck explains in [2] that the goal is to write “clean code that works”.
The TDD cycle involves five major steps to achieve this goal, where the first
couple of steps deal with the “that works” part and the last step with the
“clean code” part of the problem. In order to keep the programmer focused
and to let him know when to stop he should maintain a to-do list during the
entire development process. The list keeps track of test cases and pending
refactorings. At all times it should be kept up to date and highlight the
current test case or refactoring which is being carried out. After the to-do
list has been initialized with the first couple of test cases a unit test that
seems to be straight forward to implement is selected. This starts the TDD
cycle:
1. Add a little test.
When a unit test case is written first, the code will not compile since the
production code that is being tested is still missing. The compilation
errors should be resolved as quickly as possible with the least amount
of work, even if this means to fake a solution. Usually it takes only a
few minutes to get the code to compile.
2. Run all tests and fail.
Once a test case has been added all tests are run to see the new test
fail because the functionality which is being used has not been implemented, yet.
3. Make a little change.
The task is to make the failed test pass as quickly as possible. It does
not matter if the resulting production code does not comply with proper
software engineering and introduces “code smells” [5] to the project at
this point in the cycle. Just make a little change to get the test pass.
4. Run all the tests and succeed.
All tests are run to see the new test succeed. These steps make up the
already mentioned “that works” part.
5. Refactor to remove duplication.
While the first four steps only take a couple of minutes the programmer
now takes all the time he needs to refactor the production code as well
as the unit tests to eliminate duplication. It is important to complete
the TDD cycle because the first four steps will not deliver “clean code
that works” without the last step. During the refactoring phase all tests
are run frequently to ensure that a change did not break anything.
After a complete cycle, the covered test can be marked off the to-do list and
a new test is picked to initiate the next iteration. During this workflow a
programmer will most likely come across new test cases and refactorings that
need to be done. So, they are appended to the to-do list. A test case remains
on the to-do list if it is not possible to eliminate it’s duplication at the current
stage. Instead of backing up a programmer should work forward to get into
the position of refactoring the duplication eventually.
Gunjan Doshi depicts a summary of this procedure and refers to it as the
“Test-Driven Development Rhythm” [8].
326
1 Introduction
Figure 1: Test-Driven Development Rhythm [8]
Notice how the first four steps only take a few minutes. These steps
are done as quickly as possible in order to stay focused. Changes that
are obvious but time consuming are added to the to-do list for later iterations.
The following rules can be used as a guideline for the TDD workflow:
1. Always write a test before the production code.
2. New code is only added if there is a failing test case.
3. Don’t just run a single automated test, instead run all tests.
327
4. Duplication has to be removed as far as possible before proceeding with
a new test.
5. Never write multiple failing tests.
1.2
Essential Skills for TDD
The TDD workflow consists of several steps with no fixed size which opens up
plenty of opportunities for a TDD beginner to violate this technique. Therefore it takes discipline to stick to the TDD cycle. In [2] Kent Beck disciplines
himself by pretending to slap the back of his hand with a ruler every time he
is about to break a TDD principle.
Another TDD trait is to be able to proceed in tiny steps such that the workflow can progress at a steady pace even for none trivial problems.
Test Driven Development relies on automated tests, hence mastering a unit
testing framework is essential to TDD. This does not mean to just being able
to write basic unit tests, but to know how to apply test patterns that are
appropriate for the current unit test case under development.
Since a vast amount of time is reserved for eliminating duplication to keep
the code as clean as possible, being in the position to detect duplication (i.e.
“code smells” [5]) and to apply appropriate refactorings which also implies
knowledge in the realm of design patterns are skills that should not be absent
of a programmer’s tool box.
It is crucial to realize that these skills are necessary and take time to develop. Untrained programmers who try to apply TDD might come up with
superficial test cases which tend to result in deceptive confidence in the code.
1.3
Claimed Benefits and Effects of TDD
Proponents of the Test Driven Development practice claim that TDD has
positive impacts on the software development process. Writing tests before
the production code sets the programmer’s view to be immediately concerned
with creating interfaces, leading to testable and callable code which promotes
the decoupling of system components [10].
Automated test suites produced by the TDD technique help in preventing
regression; and thus easing integration. It also narrows the gap between
decisions (i.e. design) and feedback (i.e. implemented functionality). This
increases the programmer’s confidence in the code which in turn reduces
the fear of breaking the system and allows for applying refactorings more
aggressively. Being in the position to quickly receive feedback on newly added
functionality might increase development productivity because defects can
328
2 Empirical Studies
be located much earlier and faster in the process, reducing debugging time.
Additionally higher quality of the end product might be a result in terms of
defect density.
The unit test cases give examples on how to use the production code and
thereby form a documentation which stays current because it is compilable
and executable. Now, it is safe to execute the documentation.
Because there are no big up front designs involved in TDD’s micro iterations,
Test Driven Development yields systems that are capable of easily adapting
to late requirement changes.
2
Empirical Studies
The results of several empirical studies in form of case studies and controlled
experiments that have been conducted in order to partially validate the anecdotal benefits of Test Driven Development will be discussed in the following
two subsections.
2.1
Case Studies
Case studies involve an in depth examination of a particular case, collecting
data, analyzing and reporting results. In turn they support a researcher in
understanding a certain phenomenon and lead to new ideas for future experiments. Rather than validating hypotheses, case studies assist in generating
hypotheses.
2.1.1
Descriptions
IBM Retail Store Solutions (RSS) conducted a case study on Test Driven Development [11] in connection with their “JavaPOS” (Java for Point of Sale)
product, which defines a library of JavaBeans for accessing point of sale devices, such as printers, cash drawers, bar code readers and the like.
The case study was motivated by the fact that after the functional verification test phase of previous JavaPOS versions, it was encountered that the
defect density was not reduced on any new revision, although the developers
were highly experienced in the JavaPOS specification and POS devices.
The applied development process consisted of iterative design, implementation and testing phases, where testing was performed as a post coding
activity. None of the unit tests where automated and apparently did not survive a succeeding release. Therefore the management was open for a change
and a different development approach was sought to overcome this problem.
A new development team consisting of nine full-time software engineers had
329
the task to reimplement the JavaPOS specification using Test Driven Development. However, as potentially money was at risk several questions arose
which had to be assessed.
1. How will the defect rate be affected?
2. What will be the impact on developer productivity?
3. Will TDD lead to a more robust design?
4. Will TDD result in smoother code integration?
In order to answer these questions, the newly developed JavaPOS software
was compared to an updated legacy implementation which provided similar
functionality.
According to the following defect and test progression curve (figure 2), the
realized defect density of the legacy system was consistently higher than the
expected defect density resulting in an average of about 7.0 errors per KLOC.
Figure 2: Functional verification test defect projection - Legacy
Project [11]
In contrast, the new JavaPOS system which had been developed with TDD
resulted in 71.4 KLOC of new code and about 262 defects, averaging to 3.7
errors per KLOC (figure 3). Hence, the new team apparently experienced a
50% reduction in defect density.
330
2 Empirical Studies
Figure 3: Functional verification test defect projection - TDD Project [11]
The productivity rate in terms of LOC per person month for the new system
was slightly below the expected rate which was estimated by studying post
historical data of similar projects.
New POS devices had been added about two thirds of the way through the
schedule without any problems. This suggests that the evolved design was
able to adapt to late requirement changes.
Daily integration indicated the progress of the project and reduced risks,
since problems were detected much earlier.
The case study concludes that these effects were caused by employing Test
Driven Development.
However there are a couple of inconsistencies. While the new JavaPOS implementation had 71.4 KLOC, the size of the legacy system was not stated.
At the same time the total amount of defects of the new and the legacy system were 247 and 80, respectively. Therefore it is entirely unclear whether or
not the stated defect rate for the legacy system is only based on the updated
code. Also the fact that the two teams were differently experienced was ignored. This does not allow for a coherent conclusion that the effects can be
solely traced back to the fact that Test Driven Development was used.
2.1.2
Resulting Hypotheses
Even though the case study at IBM does not deliver any conclusive results
regarding Test Driven Development, the following hypotheses can be derived:
1. TDD reduces the defect rate.
331
2. TDD increases programmer productivity.
3. TDD leads to more robust designs.
2.2
Controlled Experiments
In a controlled experiment, a control group can be compared to an experiment
group to demonstrate a cause and effect hypothesis. The two groups are used
to illustrate that a phenomenon occurs in the presence of an action which
is applied to the subjects and does not occur in the absence of the action.
Both groups should be identical except for the one aspect whose effect is
being tested. Thus, controlled experiments can be used to falsify or verify a
hypothesis.
2.2.1
Experiment 1: “Experiment about Test-first programming”
Description and Experimental Design In 2001, Müller and Hagner conducted a controlled experiment which compared Test-First programming to
traditional programming [12]. It involved 19 computer science graduate students, who had previously participated in an Extreme Programming practical
course. The controlled independent variable of the experiment was whether
the subjects used Test-First or a traditional (design, code, test) development
process. They divided the students into a Test-First group (TFG) consisting
of 10 programmers and a control group (CG) consisting of 9 programmers
who employed the traditional development process. In order to be able to
obtain conclusive results with respect to programmer productivity, code quality, and program understanding the dependent variables; overall development
time, program reliability and the number of reused methods were of particular interest.
Each of the 19 programmers had to solve the same problem. The main class
of a graph library had to be implemented. All method declarations and comments of the class were given, such that only the method bodies had to be
completed.
Two distinct phases had to be carried out by each subject:
1. Implementation phase IP, during which each student developed the
graph library until they thought their program would run correctly.
2. Acceptance test phase AP, during which the students had to fix any
faults that were detected by the acceptance test.
The researchers used a modified version of the JUnit framework [9] to facilitate automated testing for their analysis. The acceptance test was used
332
2 Empirical Studies
to ensure a minimal code quality of the delivered programs and both groups
knew about the acceptance test right from the beginning of the experiment.
Quantitative Results The measured problem solving time of both groups
showed only a small difference. It could be observed that the TFG had a
slightly increased programming effort. Therefore, as opposed to their initial
expectations the researchers concluded that TDD is not more efficient than
the traditional development process.
In order to evaluate program reliability, the portion of passed assertions over
all possible assertions was measured for the acceptance test as well as for
a random test which invoked method calls of a given implementation in a
randomized fashion. To ensure that common methods, such as the insert operation were called more frequently than less usual operations, each method
was given a corresponding weight.
For the final programs, it is remarkable that five implementations of the TFG
achieved a reliability of over 96% at the random test compared to only one
of the implementations of the CG. However, due to a large variance in the
data points it could not be inferred that the difference in the medians (i.e.
median(TFG)=91%, median(CG)=84%) suggests an advantage of TDD with
respect to reliability. Interestingly, for the first run of the acceptance test and
the random test right after the implementation phase it turned out that in
either case the programs of the TFG were less reliable than the programs of
the CG. This gives raise to the following speculative questions, which could
not be answered by this experiment:
1. Did TDD give the TFG a false sense of security, because all their tests
were running all the time without covering the major defects?
2. Did the knowledge about the acceptance test motivate the CG to test
their programs more thoroughly after the implementation?
3. Did the TFG regard the acceptance test just as another feed back loop
as they were used to from their own test cases?
4. Did the TFG did not apply the TDD technique correctly because they
were not experienced enough?
Based on these results the researchers could not conclude that TDD increases
code quality.
The analysis of code reuse in terms of the total number of reused methods
and the total number of failed method calls exhibited a negligible difference
for either group. However, the Test-First group had significantly less errors
333
when reusing a method more than once. This suggests that TDD increases
the program understandability, because once a defect is detected by a unit
test case the programmer will learn how to use the method correctly by fixing
the fault before continuing with the next step in the TDD workflow.
Internal Validity Internal validity of the experiment was threatened by the
fact that the independent variable was not technically controlled. While
the members of the Test-First group were asked to use the TDD technique,
this requirement was only monitored by occasionally asking the subjects if
they managed to handle this development approach. Thus, no objective
measurement that could confirm compliance with the TDD workflow exists.
External Validity Since the computer science students were no professional
software developers and only had a limited experience with Test Driven Development, which possibly did not allow to turn the steps of the TDD process
into motor actions, yet; the drawn conclusions might not be applicable within
an industrial context. Furthermore, working environments that deviate from
the experimental setting might impact on the effectiveness of TDD, which
constricts genaralizability.
Summary Within its contextual limitations (e.g. small sample size, limited experience with TDD, partially large variance of collected data and the
discussed validity), the experiment yields the following results:
1. TDD does not increase programmer productivity when it is compared
to a traditional development process.
2. Due to the large variance of the data points, it cannot be concluded
that TDD yields higher quality programs.
3. TDD supports better program understanding with respect to code
reuse.
2.2.2
Experiment 2: “An Initial Investigation of Test Driven
Development in Industry”
Description and Experimental Design In their experiment, George and
Williams tried to assess the following hypotheses:
1. TDD leads to superior external code quality in comparison to code that
has been developed with a traditional development process.
334
2 Empirical Studies
2. TDD increases programmer productivity in the sense that programmers
who practice TDD will develop code faster than programmers who use
a traditional waterfall approach.
In order to do so, they arranged three TDD experimental trials with 24 professional software developers from three different companies (John Deere,
RoleModel Software, and Ericsson) [6]. Each experimental trial involved
eight randomly assigned developers, split into a TDD group and a control
group, which were asked to solve a given task using TDD and a traditional
waterfall process, respectively. Both groups used pair programming [1] to
tackle the problem which came in form of a set of requirements for a small
(approximately 200 LOC) java bowling game. As soon as the programmers
thought their implementation would meet the requirements they submitted
it for analysis.
The independent variable of this experiment was whether TDD or a waterfalllike practice was used. External code quality was measured in terms of passed
black box test cases and programmer productivity with respect to total development time.
In the initial design of the experiment, the control group was not required
to write automated tests and the researchers provided an acceptance test.
However, after the first experimental trial it turned out that some of the
delivered programs did not handle all error conditions, since the initial pairs
stopped development as soon as they passed the acceptance test. Thus, the
experimental design was adjusted for the remaining two trials, such that no
acceptance test was provided and the control group was supposed to to write
automated tests after the implementation of the game was done.
Furthermore, a survey was conducted among the developers to obtain additional qualitative results with respect to productivity, effectivity, and ease of
learning TDD.
Quantitative Results Although the experiment design had slightly changed
after the first run, the collected data of all three experimental trials was included in the analysis.
External code quality was indicated by the number of passed black box test
cases. This validated to which degree the requirement specification was met,
as well as the robustness of the implementation (i.e. error handling). The
resulting data points from all 6 TDD and 6 control pairs show, that approximately 18% more test cases were passed by the TDD pairs’ games. This
suggests that TDD increases external code quality.
Productivity was measured in terms of over all development time. Here, the
obtained data showed that on average the TDD pair took 16% more time,
335
while the medians were nearly identical, which suggests that programmers
who practice TDD are not more productive. However, it is questionable
whether or not this difference was due to the fact that almost no control
pair took their time to write automated tests as they were supposed to.
The researchers also found a moderate correlation between productivity and
quality, which opens up the possibility that the higher quality was not solely
the result of TDD but also a result of the increased time. This makes the
comparison somewhat uneven. But, since all pairs submitted their programs
once they thought they would run correctly, it is remarkable that the TDD
pairs did not hand in their code until they wrote higher quality code.
Qualitative Results All 24 developers participated in a survey which consisted of nine questions. These nine questions were aimed to elicit the programmers’ opinions regarding productivity, effectiveness and how difficult
the practice is to adopt. For programmer productivity it turned out that
87.5% of the developers thought that TDD facilitates better requirement understanding and 95.8% were convinced that TDD reduces debugging time.
The average of all positive comments yields that approximately 78% of programmers believed that TDD improves programmer productivity.
Concerning effectiveness, 92% of developers thought that TDD leads to
higher code quality, 79% believed that TDD promotes simpler desing and
71% figured that the technique was noticebly effective. Thus, averaging these
scores yields that 80% thought that TDD is effective.
About 56% of the respondents thought that getting into the TDD mindset
was difficult, while only 23% thought that the missing up front design phase
was not obstructive. This exhibits that on average 40% of the professional
developers believed that the TDD approach is hard to adopt.
Internal Validity Similarly to Müller and Hagners’ experiment the independent variable was not technically controlled. This might be a potential
threat to the internal validity of the experiment since some of the professional
developers had only a three week experience in TDD, which could blur the
cause-effect relationship between the employed development technique and
the observed results of the dependent variables.
External Validity The following limitations of the experimental design restrict the generalizability of the discussed results.
The size of the programming task (200 LOC) was very small compared to a
typical business application. Thus, the obtained results might not scale for
a real world application.
336
2 Empirical Studies
The subjects used pair programming in addition to TDD to solve the given
problem. Hence, the results apply to the combination of TDD and pair programming.
Another threat to the validity of the experiment is the fact that the experimental design was modified after the first trial. Also the sample size with 6
TDD pairs and 6 control group pairs was rather small.
Summary Clearly, the usage of professional software developers in their
own working environment can be considered as strength of the experiment.
However, weaknesses such as the modification of the experimental design
have to be kept in mind while looking at the results. Since, TDD was not
isolated from the pair programming practice there is little evidence that the
positive results of the TDD group was solely caused by the test first technique.
This said, within its contextual limitations the following two results could be
obtained:
1. The process involving TDD yields better code quality compared to code
that was produced by a traditional waterfall like development process.
2. Programmer productivity in terms of overall development time was not
increased by the employed TDD process.
2.2.3
Experiment 3: “A Prototype Empirical Evaluation of Test
Driven Development”
Description and Experimental Design For their experiment Geras, Smith,
and Miller chose a slightly different design than the ones that were previously
discussed [12], [6]. The participants were divided into two groups (i.e. group
1 and group 2), where each subject of either group had to write two different programs. While group 1 developers implemented program A with
a Test-Last process and program B with a Test-First process, the second
group developed program A with a Test-First process and program B with
a Test-Last process. Automated tests were categorized into developer tests
and customer tests. As in the previous experiments a customized JUnit [9]
version was used for the developer tests. The researchers created a new
testing framework for the customer tests, called VBExpect. This was done
because in industry customer tests and developer tests usually take place on
different testing frameworks. Hence, in addition to writing developer tests
the programmers had to translate requirements into customer tests. This
is one aspect that was not covered by the previous experiments. Thus, the
use of Test-First versus Test-Last makes up the single controlled independent
variable of this experiment.
337
Both programming tasks were primarily aimed to simulate business domain
problems. Program A was a simple command line tool that permits a user
to register a new project in a database. Program B, also a command line application, lets a user record work effort against a project task in a database.
While program A contained almost no business logic, program B involved
some business as well as data presentation logic. Therefore, program B was
slightly more complex than program A which was intended to model a relatively simple standard scenario in a business domain. Both tasks came in
form of a set of requirements.
The programmers were all professional software developers with a work experience ranging from 6 months to over 6 years. Since, participation was voluntary, there were only 14 programmers in total. In addition to the already
mentioned testing frameworks and requirements specification, each subject
was equipped with detailed descriptions for the Test-First and Test-Last process to increase experimental control. The developed solutions of both programs had to be handed in anonymously via a web portal.
The major goals of this experiment were to evaluate the effects of TDD at the
customer and developer test levels with respect to developer effort, testing,
and failure rate.
Quantitative Results Instead of just comparing the measured development
times for the Test-First development (TFD) process and the Test-Last development (TLD) process, the researches normalized the data with estimates
they had obtained from a group of industry experts. Ideal programming
hours was the unit they assigned to these time estimates with which the actual effort per ideal programming hour was calculated for each program as
shown by the following box plot diagram.
338
2 Empirical Studies
Figure 4: Developer effort per ideal programming hour (in minutes) [7]
From the plot, as seen in figure 4, the researchers concluded that the TFD
process does not reduce programmer productivity.
The log files of the partially modified testing frameworks delivered the data
for the testing effort analysis. Figure 5 shows that the developers who used
the test first approach tended to write more developer test cases as well as
customer tests. If there was a correlation between the number of test cases
and achieved code quality, this would mean that the test first process might
lead to higher program quality than the test last process. From the results
presented in figure 6, it seems that while the applied development process
causes hardly any difference regarding developer tests, test-first developers
seem to write more customer tests for each feature than test-last developers.
Since, customer tests directly reflect the requirements this might be another
positive effect of TDD.
The researchers also tried to answer the question whether or not TDD encourages developers to run tests more frequently than programmers who use
TLD. In their analysis they considered the number of test executions per
hour and came to the result that despite a relatively large variation of the
data points, Test-First developers tend to run tests more often than TestLast developers.
The measurement of unplanned failures was intended to shed light on the direct progression of a programmer during the development process, as a high
unplanned failure rate suggests a rather experimental programming style.
339
Figure 5: Test case density
(tests per kloc) [7]
Figure 6: Test case density
(tests per ideal programming
hour) [7]
Since, planned failures are an integral part of the TDD technique as opposed
to the TLD practice, the researchers modified the testing frameworks in such
a manner, that for every test assertion the developers had to state their intent to whether or not the test condition would pass. Test conditions which
turned out to violate the stated intention were counted as an unplanned failure. From the measured values, as seen in figure 7, the researchers stated
that these results were inconclusive when considering Test-First vs. TestLast analysis. However, by inspecting developer tests versus customer tests,
they explain that the results might reflect the developer’s discomfort with
customer tests.
What remains questionable, is what side effects this modification had on the
TDD workflow, since in TDD all newly added test cases are supposed to fail
before they pass. This implies that for all assertions the initial intention has
to be revised at a later step, which might obstruct the workflow. However,
this is not the case for the TLD technique.
340
2 Empirical Studies
Figure 7: Unplanned failures per test case [7]
Internal Validity While Geras, Smith and Miller provided process descriptions, the professional software developers were allowed to work on their own
time in their own working environment, which opens up the possibility that
the programmers did not follow each step in those process descriptions. This
means that similarly to the previous experiments the independent variable
was not technically controlled.
External Validity External validity is jeopardized by the fact that the samples were chosen on a voluntary basis rather than randomly, which might
have introduced strong biases.
Another concern is the size of the target programs. Even though the programs model applications that stem from a business domain, they are not
truly representative for a real world business application. While the programs
mimic the learning process in early iterations by their varying complexities,
they do not model succeeding iterations.
Also the researchers did not mention how much experience the developers
had with test driven development prior to the experiment.
Summary Based on the discussed quantitative results, the researchers concluded that the Test-First practice may not require more effort than a traditional Test-Last process, but it may support developers in writing more tests
and execute them more frequently. However, they did not state whether or
not there was a correlation between the number of tests and the code quality
of the final programs.
341
2.2.4
Experiment 4: “On the Effectiveness of Test-first Approach to
Programming”
Description and Experimental Design In 2003, Erdogmus, Morisio, and
Torchiano conducted a formal experiment in an academic setting with the
goal to compare Test-First programming with Test-Last programming with
respect to external quality and programmer productivity [3]. They adjusted
their experimental design to overcome some of the weaknesses of earlier studies [12], [6]. Instead of providing subjects with predefined interfaces, which
would have constrained the solution space, they used high-level requirements
that were divided into unique features for the experimental task. This alleviated the problem of subjects, who used a waterfall like development approach,
not writing any tests, since the unique features were given to them one at a
time in a specific order such that an incremental development process could
be mimicked. Thus, testing and coding activities could be easily interleaved
which helped the programmers of either group (i.e. Test-First and Test-Last
group) to write tests and therefore eliminated short-term productivity advantages for a group that would not have written any tests, otherwise. In
order to achieve their experimental goals the researchers used a two-stage
model for their hypotheses as seen in figure 8.
Figure 8: Two-stage hypotheses model [3]
Where stage 1 hypotheses were the following:
• 1T: Test-First programmers write more tests.
• 1Q: Test-First programmers produce a higher quality product.
• 1P: Test-First programmers are more productive.
342
2 Empirical Studies
and stage 2 hypotheses:
• 2Q: Higher number of tests implies higher quality product.
• 2P: Higher number of tests implies higher productivity.
Again, the independent variable was whether a Test-First or a Test-Last
technique was applied. The main dependent variables of the experiment
were code quality, programmer productivity, and the number of tests per
unit effort, which was also used as an intermediate variable. While stage 1
hypotheses assumed a direct effect between the independent variable and the
dependent variables, stage 2 hypotheses involved the intermediate variable
to detect causal relationships that were triggered by a chain effect. Namely,
if hypotheses 1T and 2Q were accepted, one could infer that TDD leads to
better quality because it caused programmers to write more tests. Hypotheses 1T and 2P behave analogously.
The experiment was carried out during a third year undergraduate computer
science course on object oriented programming. A prequestionnaire assessed
the experience and skills of the participants to stratify the subjects with
respect to their skill level before they were randomly assigned to one of the
two groups. Before they started to work on the experiment task, both groups
were trained in the corresponding development technique during concurrent
sessions. The programming task was the same Java bowling game as George
and Williams had previously used in their TDD study [6]. However, this time
the requirements were split up into separate stories which were building on
one another, requiring the students to incrementally implement the stories
one at a time in a specific order. This had the advantage that even partially
completed programs could be evaluated, since the researchers provided black
box acceptance tests for each story. All tests (acceptance tests and developer
tests) were created with the JUnit [9] testing framework. While the subjects
knew about the goals of the experiment (comparison of Test-First vs. TestLast with respect to productivity and quality), neither the acceptance tests
nor the hypotheses were revealed to them.
Quantitative Results The researchers analyzed the data of 24 subjects, 11
were in the Test-First group (TFG) and 13 in the Test-Last group (TLG).
The number of programmer tests written by a subject were measured per
unit of programming effort. Ineffective test cases were filtered out through
visual inspection. Since, no dead line for the final programs were issued,
the variation in total programming effort was large, such that the number of
tests had to be normalized by the total programming effort. As can be seen
in figure 9, both the median (dot on horizontal line) and the mean (floating
343
dot) of the tests were considerably higher for the TFG than for the TLG.
Also, the 25% and 75% limits were both higher for the Test-First group. In
their analysis the researchers found these results to be statistically significant
and therefore accepted hypothesis 1T.
Program quality was based on the number of failed assertions per story, where
only delivered stories were considered. A story was counted as delivered if it
passed at least 50% of the corresponding acceptance test assertions. Since,
the stories had different difficulty levels, they were weighted by the number
of assertions, such that the achieved quality was given by the weighted average over all delivered stories. The corresponding box plot in figure 9 shows
that, while the means were very close, the median for the TLG was approximately 10% higher than for the TFG. Also, both quantiles were lower for
the TFG, thus suggesting a slight quality advantage for the test last group.
After further statistical tests, the researchers could not accept hypothesis 1Q
and concluded that there were no significant quality differences between the
two groups.
The productivity measure was obtained by normalizing the number of delivered stories by total programming effort. The associated box plot representation of the collected productivity data in figure 9 shows that both, median
and mean are higher for the Test-First group. However, while the 75% limit
is much higher for the TFG, the 25% quantile is slightly below the one of the
TLG. The researchers could not accept hypothesis 1P at this point because
the results turned out to be not statistically significant. Because of the remarkable differences between the means and the 75% limits, the stage two
hypotheses were used for further investigations.
Interestingly the researchers found a linear relationship between the number
of tests and productivity and accepted hypothesis 2P.
Hypothesis 2Q could not be accepted because the obtained data did not
predict a linear relationship between the number of tests and quality.
Figure 9: Boxplots for number of tests, productivity and quality [3]
344
3 Suggestions for Future Experiments
Internal Validity A major threat to internal validity was the degree to
which the subjects deviated from the prescribed development process. Therefore the researchers enlightened the subjects about the importance of precisely following the assigned technique. They also tried to narrow down this
threat by assessing process conformance through a postquestionnaire as well
as neglecting subjects that had not written any tests for at least half the
stories.
Another threat to internal validity stemmed from the use of small stories,
which apparently tend to increase the overhead of testing. If the development techniques had different impacts on this testing overhead, the results
might not be as meaningful.
External Validity As the researchers used the same programming task as
George and Williams [6], the same threats to external validity apply with
respect to application size, as previously discussed in subsection 2.2.2.
The generalizability of the results could be limited by the fact that the subjects were undergraduate students and not professional software developers.
However, the authors argue that this might even be an advantage, because
effective application of TDD requires high skills and discipline and since students were able to effectively apply the technique, professional developers
should be able to achieve even more dramatic improvements.
Summary The main result of the experiment yields that Test-First programmers write more tests per unit of programming effort and that a higher
number of programmer tests leads to a higher level of productivity. Therefore, the researchers concluded that through a chain effect, TDD seems to
improve productivity.
However, Test-First programming did not result in higher quality on average,
but independent of the employed technique, more tests appeared to improve
the minimum quality achievable and to decrease the variation. Again, the
observations were limited within its context (e.g. incremental development
process, undergraduate students).
3
Suggestions for Future Experiments
All four controlled experiments [12], [6], [7], [3] showed weaknesses regarding
process conformance. Future experiments could be improved by introducing
a software tool that measures to which degree subjects follow a prescribed
development process. Since, most experiment tasks had to be implemented
in java, and since the Eclipse IDE [4] is widely used for java projects in
345
industry as well as in academic settings, such a tool could be realized as
an Eclipse plug-in. The plug-in could for example visualize which step the
programmer is currently carrying out and log all programmer activities (e.g.
writing production code, running unit tests, running the application etc.).
On completion of a process step, the programmer would interact with the
tool to advance to the next possible step. Thus, the plug-in would not only
be able to check programmer activities for a specific step, but also guide the
programmer through the development process. This might even assimilate
programmer skills with respect to the employed technique.
Another aspect, that is not discussed in any of these experiments is the effect
of Test Driven Development on the design and structure of the resulting programs which may have serious effects on long term productivity and quality.
This is particularly important, considering that a large portion of software development costs are caused by maintenance issues. While Erdogmus, Morisio,
and Torchiano divide the programming task into separate stories, that apparently emulate late requirement changes [3], they do not make any explicit
statements on how well TDD manages to handle these changes. Therefore,
the experiment could be extended such that the evolving design of the delivered stories is measured in terms of software metrics.
Since, the sample size in the experiments tended to be rather small, future
experiments should acquire more subjects in order to decrease the sampling
error.
4
Conclusion
From the discussed empirical studies it becomes clear, that it is quite difficult to isolate a single aspect of a software development process in order to
attribute certain observations solely to this aspect. It is also very difficult to
estimate what effects potential flaws in an experimental design have on the
inferred results.
Experimental weaknesses regarding programming tasks, correctness, effects
and process conformance cannot be ignored, when viewing the outcome of
these studies. Thus, the main results of all five studies (Table 1) have to
be seen within the limitations of their contexts. However, it is interesting
to see how the later studies adjusted their designs in oder to overcome some
of the weaknesses of earlier experiments. This is especially true for the last
empirical study [3].
While these empirical studies do not deliver a complete evaluation of Test
Driven Development at this point, they support some of the benefits that
TDD proponents claim. From most of these studies it could be observed
346
References
that Test-First programmers in comparison to Test-Last programmers tend
to write more test cases. There were also some promising attempts on relating the number of test cases to the claimed benefits. What remains unclear
is how the effectiveness of TDD depends on the individual skill level and
how long it takes to master this technique. Therefore, these studies should
encourage researchers to extend experiments for further investigations and
in turn support them to revise the theories on TDD.
Study
Type
Results
Müller and Hagner 2002
Experiment
TDD does neither improve quality nor
productivity, but improves program
understanding.
Maximilien and Williams 2003
Case Study
TDD improves quality, but there is
hardly any difference in productivity.
George and Williams 2003
Experiment
While TDD improves quality, it does
not produce better productivity.
Geras, Smith, Miller 2004
Experiment
There is no difference in productivity, but TDD encourages developers to
write more test cases and to execute
them more frequently.
Erdogmus, Morisio, Torchiano 2005
Experiment
TDD encourages programmers to write
more tests and a higher number of tests
leads to higher productivity. TDD
does not improve quality on average,
but with the higher number of tests
it increases the minimum achievable
quality.
Table 1: Results of empirical studies on TDD
References
[1] Beck, K., Extreme Programming Explained:
Addison-Wesley, 1999.
Embrace Change.:
[2] Beck, K., Test-Driven Development: By Example.: Addison-Wesley,
2003.
[3] Erdogmus, H., Morisio, M., and Torchiano, M., “On the Effectiveness of
the Test-first Approach to Programming,” IEEE Transactions on Software Engineering, Vol. 31, No. 1, 2005.
[4] http://www.eclipse.org
[5] Fowler, M., Refactoring: Improving the Design of Existing Code.:
Addison-Wesley, 1999.
347
[6] George, B. and Williams, L., “An Initial Investigation of Test Driven
Development in Industry,” presented at ACM Symposium on Applied
Computing, Melbourne, Florida, 2003.
[7] Geras, A., Smith, M. and Miller, J., “A Prototype Empirical Evaluation of Test Driven Development,” Proceedings of the 10th International
Symposium on Software Metrics, Chicago, Illinois, 2004.
[8] http://www.gunjandoshi.com
[9] http://www.junit.org
[10] Martin, R. C., Agile Software Development: Principles, Patterns, and
Practices.: Prentice Hall 2002.
[11] Maximilien, E. M. and Williams, L., “Assessing Test-Driven Development at IBM,” Proceedings of the 25th International Conference on
Software Engineering, 2003.
[12] Müller, M. and Hagner, O., “Experiment about Test-first programming,”
presented at Conference on Empirical Assessment In Software Engineering, Keele, 2002.
348

Seminar Methoden der empirischen Softwaretechnik

Transcrição

Documentos relacionados

Antrag für Einzelpersonen - Verein der Karlsruher Software

Antrag für Firmen - Verein der Karlsruher Software

Experiment: Die Wasserrose

Experimente und deren Erkenntnisse

Verschraubung Poster V11

Abschnitt 10 - Mathematisches Institut der Universität Bonn

Sozialer Einfluss in Gruppen 1

Programming through manual guidance and graphical

Experimental stimuli and their German translation

Szene aus dem Standford-Prison-Experiment. Oben