Visuelle Analyse von Open-Source-Projekten · 1.2 Begriffsbestimmung Raymond beschreibt die Grundlagen der erfolgreichen Entwicklung hochwerti-ger Softwareprojekte durch offene Zusammenarbeit

Fakultät für Mathematik und InformatikLehrgebiet Kooperative SystemeProf. Dr. Jörg M. HaakeUniversitätsstr. 158084 Hagen

Bachelorarbeit

Visuelle Analyse vonOpen-Source-Projekten

cand. B.Sc. Heiko SchlenkerMatrikel-Nr. 6390609

12. Oktober 2009

Betreut durch Dr. Till Schümmer

Inhaltsverzeichnis

1 Einführung 11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Begriffsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.1 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Kooperation, Kollaboration . . . . . . . . . . . . . . . . . . 31.2.3 Soziale Interaktion . . . . . . . . . . . . . . . . . . . . . . . 41.2.4 Gruppe, Arbeitsgruppe, Team, Gruppenarbeit . . . . . . . . 41.2.5 CSCW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Anforderungsanalyse 72.1 Problem- und Fragestellung . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Interaktionsanalyse . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Indikator für Kooperation . . . . . . . . . . . . . . . . . . . 82.1.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Vorhandene Analysewerkzeuge . . . . . . . . . . . . . . . . . . . . . 132.2.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . 222.3.2 Technische Anforderungen . . . . . . . . . . . . . . . . . . . 232.3.3 Anforderungen im Überblick . . . . . . . . . . . . . . . . . . 23

3 Lösungsansatz 253.1 Berechnung von Interaktionswerten . . . . . . . . . . . . . . . . . . 25

3.1.1 Eigenschaften kooperativ erstellter Artefakte . . . . . . . . . 253.1.2 Grundlagen der Bewertung von Interaktion . . . . . . . . . . 253.1.3 Formel zur Berechnung von Interaktionswerten . . . . . . . . 263.1.4 Ebenen der Interaktionsanalyse . . . . . . . . . . . . . . . . 29

3.2 Datengewinnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1 Projektebene . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 Dateiebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Visualisierung von sozialer Interaktion . . . . . . . . . . . . . . . . 313.3.1 Musterbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Projektebene . . . . . . . . . . . . . . . . . . . . . . . . . . 33

iii

Inhaltsverzeichnis

3.3.3 Dateiebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Ausgewählte Lösungsdetails 394.1 Metriken zur Bewertung von Interaktion . . . . . . . . . . . . . . . 39

4.1.1 Projektebene . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.2 Dateiebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 Analyse individueller Beiträge . . . . . . . . . . . . . . . . . 45

4.3 Persistierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 Entstehungsgeschichte der Artefakte . . . . . . . . . . . . . 474.3.2 Artefaktübergreifende Interaktionswerte . . . . . . . . . . . 474.3.3 Artefaktbezogene Interaktionswerte . . . . . . . . . . . . . . 49

4.4 Rüstzeug zur Beantwortung der Fragestellung . . . . . . . . . . . . 504.4.1 Beantwortung der primären Fragen . . . . . . . . . . . . . . 504.4.2 Beantwortung der sekundären Fragen . . . . . . . . . . . . . 50

5 Fallstudie: Analyse von Mozilla Firefox 535.1 Visuelle Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Projektebene . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.2 Dateiebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Schlussbetrachtung 676.1 Aussagekraft der Messergebnisse . . . . . . . . . . . . . . . . . . . . 676.2 Kalibrierung der Metriken . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.1 Gewichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3 Leistungsvermögen . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.3.1 Speicherbedarf . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.2 Algorithmen und Methoden . . . . . . . . . . . . . . . . . . 706.3.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.3.4 Datengewinnung . . . . . . . . . . . . . . . . . . . . . . . . 70

6.4 Zusammenfassung der Analyseergebnisse . . . . . . . . . . . . . . . 70

Literaturverzeichnis 73

iv

Tabellenverzeichnis

2.1 Primäre Fragestellung . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Sekundäre Fragestellung . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Bewertung der Analysewerkzeuge . . . . . . . . . . . . . . . . . . . 212.4 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Darstellung der Interaktionsstärke . . . . . . . . . . . . . . . . . . . 36

4.1 Projektbezogene Metriken . . . . . . . . . . . . . . . . . . . . . . . 404.2 Dateibezogene Metriken . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Interaktionswerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

v

vi

Abbildungsverzeichnis

2.1 CVSGrab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 CodeSaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Bloof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 CVSChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Chronia (a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Chronia (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 Datei-Autor-Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 Augur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 StarGate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.10 Expertise Clouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 iTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 K3-Gratifikationssystem . . . . . . . . . . . . . . . . . . . . . . . . 323.3 DIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4 CAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5 Visualisierungskonzeption (a) . . . . . . . . . . . . . . . . . . . . . 343.6 File History Flow (a) . . . . . . . . . . . . . . . . . . . . . . . . . . 363.7 Visualisierungskonzeption (b) . . . . . . . . . . . . . . . . . . . . . 37

5.1 File History Flow (b) . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 Interaktionsschwankungen . . . . . . . . . . . . . . . . . . . . . . . 575.3 Aktivität und Interaktion (a) . . . . . . . . . . . . . . . . . . . . . 585.4 Aktivität und Interaktion (b) . . . . . . . . . . . . . . . . . . . . . 585.5 Entwickleraktivität . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.6 Interaktionsbeiträge . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.7 Kernentwickleraktivität 2002—2008 . . . . . . . . . . . . . . . . . . 605.8 Kernentwickleraktivität 2002—2004 . . . . . . . . . . . . . . . . . . 605.9 Kernentwickleraktivität 2005—2007 . . . . . . . . . . . . . . . . . . 605.10 Kernentwickleraktivität 2008 . . . . . . . . . . . . . . . . . . . . . . 615.11 File History Flow (c) . . . . . . . . . . . . . . . . . . . . . . . . . . 625.12 Interaktionsschwerpunkte . . . . . . . . . . . . . . . . . . . . . . . . 645.13 Expertenwissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

vii

viii

Listings

4.1 Datenbank-Tabelle annotationBlockTable . . . . . . . . . . . . . 474.2 Beispiel-XML-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 Datenbank-Tabelle interactionTable . . . . . . . . . . . . . . . . 494.4 Beispiel-SQL-Abfrage . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ix

x

1 EinführungDie vorliegende Abschlussarbeit beleuchtet die Natur der Zusammenarbeit zwischenEntwicklern von Open-Source-Software. Größere Open-Source-Softwareprojekte wer-den in Teamarbeit entwickelt. Lässt sich erkennen, ob die weltweit verstreutenGruppenmitglieder kooperativ, Hand in Hand oder eher individuell zusammenarbei-ten? Dazu ist die Entstehungsgeschichte des Quellcodes des Projekts Mozilla Firefoxmithilfe des um Funktionen zur Analyse und Visualisierung von sozialer Interakti-on erweiterten Eclipse-Zusatzprogramms File History Flow untersucht worden. DasAnalyseprogramm hilft dabei, Kooperation in Software-Projektteams zu erkennen,indem es Indikatoren für das Vorliegen gemeinsamer Arbeit zur Verfügung stellt.

Dieses Kapitel bietet eine Übersicht über die Motivation, Zielsetzung und Strukturder Abschlussarbeit. Darüber hinaus werden zentrale Begriffe eingeführt.

1.1 EinleitungDie folgenden Abschnitte schildern das Thema und das Ziel dieser Abschlussarbeit.Die Ausführungen schließen mit einem Überblick über den Aufbau der Arbeit.

1.1.1 MotivationSoftwareanwendungssysteme werden zunehmend in Teamarbeit entwickelt. Infol-gedessen spielt die rechnergestützte Zusammenarbeit in der Softwareentwicklungeine zentrale Rolle. Das betrifft insbesondere Open-Source-Software. Sie wird in derRegel von Teams entwickelt, deren Mitglieder weltweit verteilt sind.

Erfolgreiche Open-Source-Softwareprojekte haben dazu beigetragen, dass dasOpen-Source-Phänomen in wissenschaftlichen Kreisen auf vermehrtes Interesse stößt.Die Beschäftigung mit der sozialen Struktur von Open-Source-Entwicklergruppenoder dem Entwicklungsprozess von Open-Source-Software bildet den Schwerpunktzahlreicher Arbeiten. Allerdings scheint eine Frage noch unbeantwortet geblieben zusein: Lösen die Entwickler die Gruppenaufgabe kooperativ oder individuell? Daranknüpfen sich weitere Fragen an: Wie lässt sich Kooperation in großen Projektgruppenerkennen? Inwiefern unterscheiden sich kooperativ erstellte Projektartefakte vondenen, die in Individualarbeit entstanden? Gibt es ein Qualitätsmerkmal und lässtsich dieses messen?

1

1 Einführung

1.1.2 ZielsetzungDurch Analyse der Entwicklungsgeschichte der Artefakte eines Softwareprojektssollen genügend Anhaltspunkte gewonnen werden, um entscheiden zu können, obdie Projektartefakte von den Teammitgliedern tendenziell in enger Zusammenarbeitoder in Einzelarbeit erstellt wurden. Ziel ist, Indikatoren für Kooperation zu finden,die Stärke des Zusammenwirkens auf Zahlenwerte (Maßzahlen) abzubilden undgeeignete Formen der Visualisierung der Analyseergebnisse zu finden. Im Kern gehtes darum, Kooperation zu erkennen und die Intensität der Kooperation zu messen.Dazu soll im Zuge dieser Abschlussarbeit das Zusatzprogramm File History Flow1

für die Entwicklungsumgebung Eclipse2 um Funktionen zur Analyse und Bewertungvon sozialer Interaktion in Gruppen erweitert werden.

1.1.3 Aufbau der ArbeitKapitel 1 führt in das Thema dieser Abschlussarbeit ein und definiert zentrale Begrif-fe. Kapitel 2 schildert die konkrete Problem- und Fragestellung, prüft die Eignungvorhandener Untersuchungswerkzeuge und beschäftigt sich mit den Anforderungenan das zu entwickelnde Analyseprogramm. Kapitel 3 beschreibt den Lösungsansatzund geht dabei auf Aspekte der Interaktionsanalyse, der Datengewinnung sowie derVisualisierung sozialer Interaktion ein. Kapitel 4 präsentiert aufgewählte Detailsder Problemlösung, darunter Metriken zur Messung von Interaktion. Kapitel 5befasst sich mit der visuellen Analyse des Open-Source-Softwareprojekts MozillaFirefox mithilfe des im Rahmen dieser Abschlussarbeit programmierten Werkzeugs.Das Schlusskapitel 6 widmet sich einerseits der Aussagekraft der Messergebnisseim Hinblick auf das Erkennen und die Bewertung von Kooperation in Software-Projektteams, der Kalibrierung der Metriken sowie den Möglichkeiten zur Steigerungder Leistungsfähigkeit des Programms und fasst andererseits die Ergebnisse derAnalyse des Softwareprojekts Mozilla Firefox zusammen.

1.2 BegriffsbestimmungEinige Kernbegriffe spielen im Zusammenhang mit dem Thema dieser Abschlussar-beit eine besondere Rolle. Sie sollen deshalb an dieser Stelle eingeführt werden.

1.2.1 Open SourceSpätestens mit Eric Raymonds Abhandlung »The Cathedral and the Bazaar« [52],drang die so genannte Open-Source-Software (OSS) ins Bewusstsein der Öffentlich-keit vor. Mit dem Aufsatz erhielt die Open-Source-Bewegung quasi ihr Manifest.

1Siehe http://www.historyflow.de2Siehe http://www.eclipse.org

2

http://www.historyflow.de

http://www.eclipse.org

1.2 Begriffsbestimmung

Raymond beschreibt die Grundlagen der erfolgreichen Entwicklung hochwerti-ger Softwareprojekte durch offene Zusammenarbeit weltweit verteilter Personen:Verteilte Gruppen von gleichberechtigten Entwicklern seien effektiver als starre,hierarchische Strukturen. Eigennutz und Anerkennung bildeten eine stärkere Trieb-feder als der Gelderwerb. Die Früchte der eigenen Arbeit würden gewissermaßenverschenkt.

Der im Jahr 1998 geprägte3 Begriff Open Source4 ist vielfach Gegenstand derKritik aus dem Lager der Free-Software-Bewegung. Er diene vordergründig demMarketing und verwässere die etablierte Idee der Free Software (FS) (vgl. Stallmanin [67]). Detaillierte Ausführungen sprengten den Rahmen dieser Abschlussarbeit.Festzuhalten ist, dass Quelloffenheit ein definierendes Merkmal beider Begriffeist (vgl. [20, 28]). Der Quellcode einer Software ist einsehbar, darf verändert undvervielfältigt sowie weitergegeben werden, und zwar unter Einhaltung der Lizenz,unter der die Software gestellt wurde.

Um den Namenstreit zwischen den beiden Bewegungen zu umgehen, werden inder Literatur überwiegend die hybriden Begriffe Free/Libre Open Source Software(FLOSS), Free and Open Source Software (FOSS) oder Free/Open Source Software(F/OSS) benutzt (vgl. [53, 55]).

1.2.2 Kooperation, KollaborationDiese Abschlussarbeit beschäftigt sich mit dem Erkennen von Kooperation in FLOSS-Projektteams. Es stellt sich die Frage, was unter Kooperation zu verstehen ist.Teufel et al. [69] definieren Kooperation als Realisierung gemeinsamer Ziele durcharbeitsteilige Leistungserstellung. Der Begriff bezeichnet die gemeinsame Ausführungeiner Teilaufgabe an demselben Artefakt5 durch verteilte Aufgabenträger (vgl. [32]).Kooperation stellt den eigentlichen Akt der Zusammenarbeit dar, und zwar diegemeinsame Arbeit an den geteilten Artefakten6. Die Intensität der Zusammenarbeitist bei der Kooperation besonders hoch.

Der Begriff Kollaboration wird uneinheitlich definiert. In der englischsprachigenLiteratur bezeichnet er häufig eine lose Art der Zusammenarbeit. Er dient dann alsOberbegriff, der sämtliche soziale Interaktionsprozesse enthält:

»Collaboration is broadly defined as the interaction among two or moreindividuals and can encompass a variety of behaviors, including com-munication, information sharing, coordination, cooperation, problemsolving, and negotiation.« (Hall in [35])

3Siehe auch http://www.opensource.org/history, Abschnitt »The ‘open source’ label«4Die offizielle Definition von Open Source Software wurde auf http://www.opensource.org/docs/

osd veröffentlicht.5Artefakte repräsentieren semantische Einheiten. Dabei kann es sich zum Beispiel um Methoden,

Klassen, Dateien usw. handeln. Artefakte sind gemeinsame Objekte. Das bedeutet, dass sieallen Gruppenmitgliedern zugänglich sind.

6Im Kontext dieser Abschlussarbeit bilden Dateien die kleinsten Artefakte.

3

http://www.opensource.org/history

http://www.opensource.org/docs/osd

http://www.opensource.org/docs/osd

1 Einführung

In der deutschsprachigen Literatur werden die Begriffe Kooperation und Kollaborationhingegen meist synonym benutzt.

1.2.3 Soziale InteraktionSoziale Interaktion beschreibt das aufeinander bezogene Handeln zwischen Ak-teuren. Der Begriff bezeichnet das Geschehen zwischen Personen, die wechselsei-tig aufeinander reagieren und die sich dabei gegenseitig beeinflussen und steuern(vgl. [3, 25, 34, 51]). Nicht jede Interaktion zwischen Personen dient dazu, ein ge-meinsames Ziel zu erreichen. Zwei Schachspieler interagieren zwar, verfolgen aberantagonistische Ziele.

Interaktionsanalyse, Gruppeninteraktionswert

Das als Interaktionsanalyse bezeichnete Beobachtungsverfahren (vgl. [5]) dient zurErfassung von sozialen Beziehungen zwischen Akteuren und zur Bestimmung vonRollen in Gruppen. Häufig gibt ein Gruppeninteraktionswert oder ein Interaktions-grad die Stärke der Interaktion in Gruppen wieder. Ein Verfahren zur Berechnungvon Interaktionswerten wird in Abschnitt 3.1 auf Seite 25 vorgestellt.

Indikator für Kooperation

Kooperation fordert und fördert soziale Interaktion. Akteure, die an denselbenArtefakten arbeiten, müssen unter anderem ihre Tätigkeiten abstimmen und Infor-mationen austauschen, also miteinander kommunizieren. Dieses Zusammenwirkenmindestens zweier Personen ist soziale Interaktion. Kooperierende Akteure inter-agieren häufig und intensiv. Es liegt deshalb auf der Hand, soziale Interaktionals Indikator für Kooperation zu verwenden. Ein hoher Interaktionsgrad ist damitein Indiz für das Vorliegen von Kooperation. Interagieren die Akteure nicht, dannexistiert auch keine Kooperation. Die Frage, ob einem hohen Interaktionsgrad inder Tat Kooperation zugrundeliegt, lässt sich durch Analyse der einzelnen von denAkteuren ausgeführten Aktionen klären. Stellt sich heraus, dass die Aktionen inhalt-lich aufeinander bezogen sind und dazu dienen, ein gemeinsames Ziel zu erreichen,dann ist davon auszugehen, dass tatsächlich Kooperation vorliegt.

1.2.4 Gruppe, Arbeitsgruppe, Team, GruppenarbeitFLOSS-Projektteams sind Gruppen. Nach Schulte-Zurhausen [56] ist eine Grup-pe »eine begrenzte Anzahl von Menschen die über einen längeren Zeitraum in relativhäufiger, direkter Interaktion zueinander stehen, durch Rollendifferenzierung und ge-meinsame Normen gekennzeichnet sind und die ein Wir-Gefühl verbindet«, währendeine Arbeitsgruppe eine Gruppe ist, »deren Mitglieder eine gemeinsame Aufgabefunktions- und arbeitsteilig durchführen«.

4

1.2 Begriffsbestimmung

Teufel et al. [69] betrachten ein Team als eine »Arbeitsgruppe, deren Mitglie-der den Willen haben, ein gemeinsames Ziel zu erreichen« und definieren, dassGruppenarbeit aus »den Tätigkeiten [besteht], die durch die Aufgaben bestimmtwerden, die zur Erreichung des Gruppenziels notwendig sind«, das heißt sie setzt sichaus Gruppentätigkeit, -aufgabe und -ziel zusammen. Gruppenarbeit unterliegt dreiEinflussfaktoren: Geteilte Artefakte werden von den Gruppenmitgliedern gemeinsamproduziert. Die Mitglieder müssen bei der Erfüllung der gemeinsamen Gruppenauf-gabe Nachrichten austauschen, also miteinander kommunizieren. Schließlich ist eserforderlich, dass sich die Gruppenmitglieder abstimmen, koordinieren.

1.2.5 CSCWDas Forschungsgebiet rechnergestützte Zusammenarbeit, abgekürzt CSCW7, be-schäftigt sich unter anderem mit Werkzeugen und Techniken zur Unterstützungvon Gruppenarbeit. Eine populäre Definition von CSCW stammt von Paul Wil-son [73]:

»CSCW [is] a generic term, which combines the understanding of theway people work in groups with the enabling technologies of computernetworking, and associated hardware, software, services and techniques.«

Unter CSCW-Systemen, -Applikationen, -Anwendungen oder kooperativen Sys-temen beziehungsweise unter Groupware ist gewöhnlich jede Soft- oder Hardwarezu verstehen, die Gruppenarbeit unterstützt oder ermöglicht (vgl. [69]). Die inder Regel weltweit verstreuten Mitglieder von FLOSS-Projektteams setzen solcheSysteme ein. Ohne CSCW-Systeme ließen sich zahlreiche FLOSS-Projekte gar nichtverwirklichen.

7Computer Supported Cooperative Work

5

6

2 AnforderungsanalyseDieses Kapitel präzisiert zunächst die Problem- und Fragestellung. Anschließendwerden vorhandene Analysewerkzeuge daraufhin untersucht, ob und inwiefern siegeeignet sind, das Problem zu lösen. Mit der Vorstellung der funktionalen und dentechnischen Anforderungen an das zu entwickelnde Analysewerkzeug schließt dasKapitel.

2.1 Problem- und FragestellungDie vorliegende Abschlussarbeit verfolgt das Ziel, Kooperation in FLOSS-Projekt-teams zu erkennen und zu bewerten. Sie beschäftigt sich mit dem Problem, wieProjektartefakte identifiziert werden können, die durch gemeinsame Arbeit ent-standen sind, und inwiefern sie sich von denen unterscheiden, die in Einzelarbeitproduziert wurden. Eine Metrik soll dabei als Maß für diese Eigenschaft dienenund damit die Möglichkeit zur Bewertung und zum Vergleich schaffen. Es stelltsich ferner die Frage, ob die Gruppenmitglieder vorwiegend artefaktbezogen oderartefaktübergreifend, projektweit zusammenarbeiten. Kooperation auf Dateiebenekann dann vorliegen, falls die Modifikation eines gemeinsamen Artefakts durchein Teammitglied Reaktionen anderer auslöst, die sich auf dasselbe Artefakt er-strecken. Verursachen die Aktionen jedoch Folgeaktionen, die ein anderes Artefaktbetreffen, dann liegt vermutlich artefaktübergreifende, projektweite Zusammenar-beit vor. Generell kann nur dann von Kooperation gesprochen werden, falls dasHandeln der Akteure tatsächlich aufeinander bezogen ist und zur Verwirklichungeines gemeinsamen Ziels dient.

Kooperation in Gruppen bedingt soziale Interaktion (siehe Abschnitt 1.2.3 aufSeite 4). Interagieren die Gruppenmitglieder häufig und intensiv, dann ist die Wahr-scheinlichkeit für das Vorliegen von gemeinsamer Arbeit hoch. Soziale Interaktionkann demnach Zusammenarbeit anzeigen, sie kann gewissermaßen als Indikatorfür Kooperation dienen. Ließe sich die Intensität der Interaktion auf ein Maß ab-bilden, dann läge indirekt auch ein Maß für die Kooperationsstärke vor. Falls esgelänge, Interaktionswerte bestimmten gemeinsame Artefakte zuzuordnen, läge einUnterscheidungsmerkmal vor. Mutmaßlich kooperativ erstellte Artefakte zeichnetensich im Vergleich mit in Einzelarbeit produzierten Artefakten durch einen höherenInteraktionswert aus.

7

2 Anforderungsanalyse

2.1.1 InteraktionsanalyseDie Interaktionsanalyse ist ein Beobachtungsverfahren, das sowohl zur Erfassungvon sozialen Beziehungen zwischen Personen als auch zur Bestimmung von Rollenin Gruppen dient (vgl. [5]). Zwei oder mehr Akteure interagieren, falls ihr Handelnaufeinander bezogen ist. Dabei reagieren sie wechselseitig aufeinander und beein-flussen sowie steuern sich gegenseitig. Zwei Handlungen verschiedener Akteure sinddann aufeinander bezogen, wenn sie zeitlich und logisch beziehungsweise semantischzusammenhängen. Sind diese Kriterien erfüllt, dann bilden die beiden Interaktions-handlungen ein Aktionspaar. Je dichter die Elemente eines Aktionspaars zeitlichund semantisch beieinander stehen, desto intensiver ist die Interaktion zwischen denHandlungspartnern.

2.1.2 Indikator für KooperationWie bereits in Abschnitt 1.2.3 auf Seite 4 erwähnt, ist nicht jede Interaktion Ausdruckvon Kooperation. Die Akteure könnten miteinander konkurrieren und gegensätz-liche Ziele verfolgen. Im Folgenden werden zur Komplexitätsbeherrschung einigeVereinfachungen vorgeschlagen: Es wird grundsätzlich davon ausgegangen, dassdie Mitglieder eines FLOSS-Projektteams ein gemeinsames Ziel verfolgen, nicht inKonkurrenz zueinander stehen und bemüht sind, harmonisch zusammenzuarbeiten.Konflikte, Sabotageakte und so genannte editor wars bilden den seltenen Ausnahme-fall. Die Form der sozialen Interaktion wird nicht differenziert. Es spielt keine Rolle,ob es sich um Kommunikations-, Koordinations- oder Kooperation- beziehungsweiseKollaborationshandlungen handelt. Das Handeln der Akteure manifestiert sich inÄnderungen des Quellcodes der Projektartefakte. Auch die Dimension der Inter-aktion – zum Beispiel zentral/dezentral, synchron/asynchron, implizit/explizit –wird nicht näher betrachtet. Davon abgesehen wäre es kompliziert, die Natur unddie Dimension des Interaktionsgeschehens lediglich anhand der Änderungen amQuellcode der geteilten Artefakte zu bestimmen. Dazu wäre es unter anderem nötigzu wissen, zu welchem Zeitpunkt die Aktion erfolgte, also wann der Akteur dieQuellcodeänderung durchführte. Solche Daten, die nur das vom Teammitglied zurAusführung der Aktionen benutzte Entwicklungswerkzeug erzeugen kann, stehen inder Regel nicht zur Verfügung. Wird der Quellcode der Projektartefakte von einemzentralen Versionsverwaltungssystem gespeichert, so ist lediglich in Erfahrung zubringen, wann das Gruppenmitglied das Ergebnis seiner Arbeit im Versionsverwal-tungssystem ablegte. Dieses Datum stimmt im Normalfall nicht mit dem Zeitpunktüberein, an dem der Akteur seine Änderungen am Quellcode vornahm.

Festzuhalten bleibt, dass das Vorliegen von Interaktion als Indikator für Koope-ration betrachtet wird. Ein numerischer Interaktionswert drückt die Intensität derInteraktion beziehungsweise der angezeigten Zusammenarbeit aus. Seine Höhe gibtdie logische und zeitliche Kopplung zwischen den aufeinander bezogenen Hand-lungen wieder. Je schneller eine Reaktion erfolgt und je stärker diese inhaltlichauf die auslösende Aktion bezogen ist, desto größer sollte der Interaktionswert

8

2.1 Problem- und Fragestellung

sein. Interaktionswerte liefern also Indizien für eine mögliche Kooperation. DieInteraktionswerthöhe korreliert dabei mit der Stärke der Kooperation.

2.1.3 AufgabenstellungIm Rahmen dieser Arbeit soll der Entwicklungsprozess eines FLOSS-Projekts un-tersucht werden, mit dem Ziel, Kooperation im Projektteam zu erkennen und zubewerten. Als Untersuchungsgegenstand dient das Projekt Mozilla Firefox1. Es ist dieArt und Weise von Interesse, wie die Mitglieder der Projektgruppe die gemeinsameEntwicklungsaufgabe bewältigen. Geschieht dies tendenziell in enger Kooperationoder wird das Problem gemäß einer Teile-und-herrsche-Strategie in Teilaufgabenzerlegt, die von den Mitgliedern in Einzelarbeit gelöst werden? Lässt sich die Naturder Zusammenarbeit als kooperativ, Hand in Hand, oder als individuell, selbständigbeschreiben? Crowston et al. [16] nehmen jedenfalls an, dass FLOSS-Projektteamsdarauf bedacht seien, Abhängigkeiten zu minimieren, weil das den Koordinations-aufwand verringerte. Dies spräche für die Zerlegung der gemeinsamen Aufgabe inModule und Teilaufgaben, die von den Gruppenmitgliedern unabhängig voneinanderin Einzelarbeit bearbeitet werden könnten. Ließe sich feststellen, dass der größteTeil der Artefakte eines FLOSS-Projekts nicht kooperativ entstand, dann wäre dasein Beleg für die These. Fänden sich Hinweise auf gemeinsames Arbeiten, wäre esinteressant, die Stellen im Projekt zu identifizieren, an denen Kooperation stattfand.

Tabelle 2.1: Analysegegenstand: Artefaktquellcode und dessen Historie

Primäre Fragestellung

Nr. FragePF1 Fand Kooperation statt?PF2 Wie eng war die Kooperation?

Als alleinige Datenquelle soll der Quellcode der Projektartefakte dienen. Anhandseiner Entstehungsgeschichte lässt sich nachvollziehen, welches Gruppenmitgliedzu welchem Zeitpunkt welchen Beitrag beigesteuert hat. Das Ziel ist, Einblicke indie soziale Interaktionsgeschichte zu gewinnen und Kooperation im Projektteam zudetektieren. Der Quellcode fungiert dabei gewissermaßen als Informationsträger. DieAnalyse soll unabhängig von der Programmiersprache durchgeführt werden können,die in dem zu untersuchenden FLOSS-Projekt eingesetzt wird. Es wird vorausgesetzt,dass der öffentlich zugängliche Quellcode in Form von Textdokumenten vorliegt, dievon einer Versionsverwaltung2 gesichert werden. Ein System zur Versionsverwaltunghat die Aufgabe, die Gruppenarbeit zu unterstützen und für die Konsistenz der

1Siehe http://www.mozilla.com/firefox/2Ein weit verbreitetes Softwaresystem zur Verwaltung von Quellcode ist das Concurrent Versions

System (CVS) http://www.nongnu.org/cvs/.

9

http://www.mozilla.com/firefox/

http://www.nongnu.org/cvs/


geteilten Artefakte zu sorgen. Darüber hinaus soll es die Nachvollziehbarkeit vonÄnderungen durch die Versionierung der verwalteten Artefakte gewährleisten, undzwar zu jedem Zeitpunkt. Alle Änderungen der Artefakte werden üblicherweise ineinem zentralen so genannten Repository gespeichert. Ein Versionsverwaltungssystemzeichnet somit die Geschichte der verwalteten Artefakte auf.

Mithilfe eines Analyseprogramms soll ermittelt werden, ob die Quellcodeände-rungen eines Akteurs Reaktionen auf die eines anderen Gruppenmitglieds waren.Aus diesen Wechselwirkungen leitet sich ein Interaktionswert ab, und zwar entwederfür einen beliebigen Zeitpunkt oder für einen frei wählbaren Zeitraum innerhalbder Entstehungsgeschichte des Quellcodes. Wie bereits in Abschnitt 2.1.1 auf Sei-te 8 erwähnt, dient der Interaktionswert quasi zur Bewertung der Kooperationzwischen den Gruppenmitgliedern. Je höher der Interaktionswert, desto enger istdie vermutete Kooperation. Abschnitt 3.1 auf Seite 25 geht darauf genauer ein. VomAnalyseprogramm wird erwartet, dass es die einzelnen Messergebnisse zu einemGesamtbild zusammensetzt, und zwar dergestalt, dass ein schnelles Auffinden vonauffälligen Mustern in der Zusammenarbeit und von Artefakten, die kooperativproduziert wurden, möglich ist.

Nicht nur der Gruppenprozess als Ganzes ist von Interesse, sondern auch derindividuelle Beitrag des einzelnen Mitglieds zum Gruppenfortschritt. Damit dasWirken ausgewählter Akteure isoliert betrachtet werden kann, sollte das Analysepro-gramm in der Lage sein, die Beiträge der restlichen Gruppenmitglieder auszublendenbeziehungsweise von der Analyse auszunehmen.

Im Detail soll einerseits festgestellt werden, welche Artefakte Gegenstand derKooperation waren, andererseits sollen die Artefakte vorgegeben werden können,die das Analyseprogramm untersuchen soll. Es soll auf einen Blick zu erkennen sein,ob das gewählte Artefakt in gemeinsamer Arbeit oder in Einzelarbeit entstanden ist,und zwar für jede einzelne Version des Artefakts. Dazu ist die Interaktionsgeschichtejedes gemeinsamen Artefakts so zu visualisieren, dass die chronologische Abfolge dereinzelnen Versionen klar zu erkennen ist. Der zu einer Artefaktversion gehörendeInteraktionswert soll mühelos ablesbar sein. Ferner ist von Interesse, welche Quell-codeänderungen zu einer bestimmten Version des Artefakts führten und wer derVerfasser war3. Das erleichtert die Beurteilung, ob die Beiträge eines bestimmtenTeamangehörigen inhaltlich von Bedeutung waren oder nicht.

Für Projektmanager, die den Fortschritt eines Softwareprojekts überwachen undsteuern, oder für Lehrende, die im Rahmen eines Programmierpraktikums denGruppenfortschritt verfolgen und die Ausgestaltung der Kooperation in der Gruppebeobachten, wären weitere Informationen von Nutzen. Daher wäre es wünschenswert,aber optional, etwas über die soziale Struktur des Entwicklerteams zu erfahren. Siemüsste sich aus den sozialen Interaktionen zwischen den Entwicklern ableiten lassen(vgl. [50, S. 135]). Lassen sich die Mitglieder in Untergruppen einteilen? Gibt eseine stabile Gruppe von Kernentwicklern? Ist eine Hierarchie unter den Mitgliedern

3Es stellen sich Fragen nach dem Wer, Was, Wo und Wann, die im Übrigen im Zusammenhangmit engl. awareness (Gruppenbewusstsein) eine wichtige Rolle spielen (vgl. [12, 33]).

10

2.1 Problem- und Fragestellung

Tabelle 2.2: Ein Bündel sekundärer, optionaler Fragen

Sekundäre Fragestellung

Nr. FrageSF1 Wird die soziale Struktur des Projektteams sichtbar?SF2 Gibt es Untergruppen in Gestalt einer Kernentwicklergruppe

und einer Gruppe von peripheren Entwicklern?SF3 Existiert eine Hierarchie?SF4 Wie ist die Rollenverteilung ausgestaltet?SF5 Existieren Gruppenmitglieder, die aktiver sind als andere?SF6 Arbeitet ein Entwickler bevorzugt mit anderen zusammen

oder zieht er Einzelarbeit vor?SF7 Ist zu beobachten, dass ein Gruppenmitglied häufiger mit

bestimmten Entwicklern zusammenarbeitet?SF8 Sind Rückschlüsse auf das Expertenwissen der Teammitglieder möglich?SF9 Auf welchen Arbeitsfeldern tut sich ein Entwickler besonders hervor?SF10 Gibt es ein gemeinsames Quellcodeeigentum oder gehört der Quellcode

demjenigen, der ihn geschrieben hat?SF11 Sind Rückschlüsse auf ein (agiles) Vorgehensmodell möglich?SF12 Sind Trends in der Zusammenarbeit zu beobachten?SF13 Gibt es Alarmsignale, die auf einen drohenden Misserfolg

des Projekts schließen lassen?

11


des Projektteams festzustellen? Existieren Gruppenmitglieder, die aktiver bezie-hungsweise fleißiger sind als andere4? Arbeitet ein Entwickler bevorzugt mit anderenzusammen oder zieht er Einzelarbeit vor? Ist zu beobachten, dass ein Gruppenmit-glied häufiger mit bestimmten Entwicklern zusammenarbeitet? Existieren sozialisolierte Mitglieder? Wie ist die Rollenverteilung ausgestaltet?

Darüber hinaus stellt sich die Frage, ob Rückschlüsse auf die Sachkenntnis einesTeammitglieds möglich sind? Auf welchen Arbeitsfeldern tut es sich besonders hervor?Es wäre durchaus denkbar, dass potenzielle Arbeitgeber Softwarearchive von FLOSS-Projekten benutzen könnten, um geeignete Kandidaten für die Besetzung offenerStellen zu finden.

Abschließend wäre zu prüfen, ob Aussagen im Zusammenhang mit dem Entwick-lungsprozess möglich sind. Gibt es ein gemeinsames Quellcodeeigentum oder gehörtder Quellcode dem Teammitglied, das ihn geschrieben hat? Sind Rückschlüsse aufein (agiles) Vorgehensmodell möglich?

An dieser Stelle sei ein kurzer Einschub erlaubt. Viele FLOSS-Projekte sindFreizeitprojekte. Wollten sich mehrere Teammitglieder gemeinsam einer Aufgabewidmen, dann stünden dem praktische Hemmnisse entgegen. Die Mitglieder sindin der Regel weltweit verteilt. Sie leben in unterschiedlichen Zeitzonen. SynchroneKooperation wäre deshalb kaum möglich. Blieben noch asynchrone Formen dergemeinsamen Arbeit. Die erforderten, dass sich die beteiligten Personen regelmäßigund in hoher Frequenz der geteilten Aufgabe widmen könnten. Wegen der unter-schiedlichen Freizeitsituation, wäre auch diese Anforderung schwierig zu erfüllen. Esist daher zu erwarten, dass eher Prozessmodelle anzutreffen sind, die den Schwer-punkt auf Spezialisierung und Einzelarbeit legen – sofern die Entwicklung einesFLOSS-Projekts überhaupt einem Prozess- beziehungsweise Vorgehensmodell folgt.Vorgehensmodelle, die sich durch hohe Kooperation auszeichnen, dürften bei derEntwicklung von FLOSS-Projekten eine untergeordnete Rolle spielen. Darunterfiele zum Beispiel Extreme Programming (XP) [9], allein wegen der Technik desProgrammierens in Paaren. Um zur ursprünglichen Fragestellung zurückzukehren:Die Intensität der Zusammenarbeit in der Gruppe könnte ein Indikator für daseingesetzte Vorgehensmodell sein. Einige agile Vorgehensmodelle zeichnen sich unteranderem dadurch aus, dass sie einen Schwerpunkt auf die Verteilung des Wissensauf alle Mitglieder des Projektteams legen. Die Gruppenmitglieder sollen sich in alleBereiche des Projekts einbringen. Das müsste sich in einem auffällig hohen Gradder projektweiten Zusammenarbeit widerspiegeln. Vorgehensmodelle, die hingegendie Spezialisierung der Teammitglieder hervorheben, müssten dazu führen, dassweniger stark projektweit kooperiert wird. Bestimmte Personen arbeiteten übereinen längeren Zeitraum hinweg auf bestimmte Projektartefakte bezogen zusammen,das heißt, es müsste überproportional artefaktbezogene Kooperation zu beobachtensein. Die Integration der Ergebnisse nach Abschluss der Einzelarbeitsphasen sollte zueinem sprunghaften Anstieg der projektweiten, artefaktübergreifenden Kooperation

4In der englischsprachigen Literatur wird dieses Phänomen häufig unter dem Begriff social loafingsubsumiert (vgl. [13, 38, 41]).

12

2.2 Vorhandene Analysewerkzeuge

führen. Es bilden sich möglicherweise charakteristische Kooperationsmuster heraus,die Rückschlüsse auf das Vorgehensmodell erlauben könnten.

Im Zusammenhang mit dem Controlling und Monitoring von Projekten stellensich weitere Fragen. Sind Trends in der Zusammenarbeit zu beobachten? Oderanders formuliert: Existieren Alarmsignale, die auf einen drohenden Misserfolg desProjekts schließen lassen?

All diese Fragen sind von nachrangiger Bedeutung. Es wäre schön, wenn das zuentwickelnde Analyseprogramm dabei helfen könnte, die Fragen zu beantworten.Wichtiger ist die Erfüllung der Kernaufgabe, nämlich festzustellen, ob im Verlaufder Entwicklung eines Softwareprojekts Kooperation stattfand und wie intensiv siewar. Tabelle 2.1 auf Seite 9 und Tabelle 2.2 auf Seite 11 fassen die primäre undsekundäre Fragestellung (PF, SF) zusammen.

2.2 Vorhandene AnalysewerkzeugeEs existiert eine Reihe von Programmen, die im Kontext des rechnergestütztengemeinsamen Lernens (CSCL)5 zur Interaktionsanalyse eingesetzt wurden ([6, 11,19, 24, 37, 46, 61, 63, 64]). Leider sind sie entweder eng an eine Lernumgebunggekoppelt oder sie sind auf einer niedrigen Entwicklungsstufe stehen geblieben.Keines dieser Programme ist geeignet, ein FLOSS-Projekt einer Interaktionanalyseanhand des von einer Versionsverwaltung gespeicherten Quellcodes zu unterziehen.

Ogawa et al. [47] beschreiben einen vielversprechenden Ansatz zur Visualisierungvon sozialer Interaktion in FLOSS-Projektteams. Dazu setzen sie modifizierte San-key-Diagramme6 ein. Die Autoren stellen ein Programm vor, das in erster Linie dieKommunikation mittels E-Mail zwischen den Teammitgliedern auswertet. So lässtsich erkennen, welche Projektartefakte gemeinsam bearbeitet wurden beziehungswei-se kooperativ entstanden sind. Gemäß der Aufgabenstellung (siehe Abschnitt 2.1.3auf Seite 9) sollen Strukturen der Zusammenarbeit jedoch aus dem Quellcode dergemeinsamen Artefakte abgeleitet werden. Aus diesem Grund ist das Programm fürdie geforderten Belange ungeeignet.

Viele der im Folgenden vorgestellten Programme können eine entfernte Versi-onsverwaltung als Quelle für Eingabedaten für ihre Analysen verwenden. Für sichbetrachtet, ist jedes einzelne kaum geeignet, befriedigende Antworten auf die inTabelle 2.1 auf Seite 9 zusammengestellten primären Fragen nach dem Vorliegenund der Stärke von Kooperation zu Tage zu fördern. Daher werden die Analy-seprogramme in Kombination benutzt, in der Hoffnung, in der Gesamtschau zuaufschlussreichen Resultaten zu gelangen.

Abbildung 2.1 auf der nächsten Seite zeigt CVSGrab [71], ein Programm zurVisualisierung von Softwareevolution, welches die Artefakte in Form von Streifenbeziehungsweise Balken entlang eines Zeitstrahls darstellt. Zwei Kurven zeigen dieAnzahl der Aktionen: Eine vertikale veranschaulicht dateibezogene, eine horizontal

5Computer Supported Collaborative Learning6Sankey-Diagramme dienen normalerweise zur grafischen Darstellung von Mengenflüssen.

13


Abbildung 2.1: CVSGrab [71] – Visualisierung von Softwareevolution

verlaufende bildet dateiübergreifende, projektweite Aktionen ab. CVSGrab kanngeteilte Artefakte aufspüren, die Tätigkeitsschwerpunkte bilden. Diese Artefaktelassen sich daraufhin mit CodeSaw [29] untersuchen. Das Programm verknüpft denQuellcode mit der Konversation über das gemeinsame Artefakt. Damit kann Ko-operation zwischen den Gruppenmitgliedern aufgedeckt werden, die das Artefaktbearbeiteten. Allerdings ist es nicht möglich, einen exakten Zahlenwert berechnenzu lassen, der die Intensität der Kooperation widerspiegelt. Mit anderen Worten: Esbesteht die Möglichkeit, punktuell Kooperation zwischen ausgewählten Mitgliedernder Entwicklergruppe zu entdecken. Doch in Ermangelung einer Funktion zur Be-stimmung eines Gruppeninteraktionswerts, der ein Maß für das Zusammenwirkender Gruppe ist, ist es mühsam, Erkenntnisse über den Gruppenprozess als Ganzeszu gewinnen. Abbildung 2.2 auf der nächsten Seite zeigt die Visualisierung derZusammenarbeit zweier Personen. Neben dem Zugriff auf den Quellcode der geteil-ten Artefakte, benötigt das Programm einen Zugang zum Archiv der Mailingliste,die von der Projektgruppe zur Kommunikation benutzt wird. CodeSaw zieht alsozwei Datenquellen zu Rate. Damit erfüllt das Programm nicht die zentrale Anfor-derung, ausschließlich den von einer Versionsverwaltung gespeicherten Quellcodeauszuwerten.

Pekacki entwickelte das erweiterbare Programm Bloof [23] zur Analyse derEvolution von Softwareprojekten, und zwar auf Grundlage der von einem Versi-onsverwaltungssystem vorgehaltenen Projektdaten. Bloof7 versucht anhand derEntstehungsgeschichte eines Projekts zu ermitteln, ob Gruppenmitglieder zeitlichverschränkt die gleichen Artefakte modifizierten. Arbeiteten mindestens zwei Per-sonen am selben Tag an derselben Datei, dann betrachtet das Programm das alsAusdruck von Kooperation. Die Intensität entspricht der Anzahl der kooperativen

7Siehe http://bloof.sourceforge.net

14

http://bloof.sourceforge.net


Abbildung 2.2: CodeSaw [29] – Zusammenarbeit zwischen den Personen marv_sf(cyan) und thekingant (rot). Je größer die Überdeckung der beidenden Personen zugeordneten Flächen, die das Ausmaß der Änderun-gen an den geteilten Artefakten wiedergeben, desto stärker ist dieZusammenarbeit.

Abbildung 2.3: Bloof [23] – Produktivitätsbeiträge: Wie viele Codezeilen stammenvon den Kernentwicklern?

15


Abbildung 2.4: CVSChecker [43] – Diagramm auf Dateiebene: Welches Mitgliedbearbeitete welche Datei in welchem Umfang?

Änderungen am Artefakt. Obwohl Bloof unter anderem dazu entworfen wurde, dieZusammenarbeit zwischen den Programmierern eines Projekts zu untersuchen, sinddie im Programm enthaltenen Metriken ungeeignet, genügend Anhaltspunkte zureindeutigen Beantwortung der primären Fragestellung zu liefern. So erzeugt die inForm eines einfachen Zählers implementierte Metrik zur Messung von KooperationErgebnisse, die nicht differenziert genug sind. Allerdings unterstützt das Programmden Benutzer bei der Suche nach Antworten auf einige der in Tabelle 2.2 auf Seite 11zusammengefassten sekundären Fragen wie nach Hierarchien in der Gruppe (SF2)und der Produktivität (SF5) beziehungsweise Produktivitätseinbrüchen (SF13) (sie-he auch Abbildung 2.3 auf der vorherigen Seite). Darauf soll an dieser Stelle abernicht näher eingegangen werden.

Als Nächstes bietet sich der Einsatz des Programms CVSChecker [42–44] an. Eshandelt sich um ein Zusatzprogramm für die Anwendung JRefleX [74], die für dieEntwicklungsumgebung Eclipse entwickelt wurde und zur Analyse des Entwicklungs-prozesses eines Softwareprojekts dient. Dazu bedient sie sich der von einer Versions-verwaltung aufgezeichneten Entstehungsgeschichte. Es lassen sich Erkenntnisse überdie Aktionen der Gruppenmitglieder und der Evolution der Artefakte gewinnen.Zudem liefert das Programm Hinweise auf eine mögliche Kooperation zwischen denPersonen, die dieselben Artefakte bearbeitet haben (siehe auch Abbildung 2.4). Dieprimäre Fragestellung bleibt jedoch unbeantwortet. Das Programm zeigt zwar an, obeine Datei von verschiedenen Akteuren bearbeitet wurde, lässt aber die Frage offen,ob dies tatsächlich in Kooperation geschah. CVSChecker stellt eine Datei als Säuledar, wobei die Länge der Säulensegmente die Anzahl der Quellcodezeilen wiedergibt,die hinzugefügt oder entfernt wurden. Die Segmentfarbe referenziert den Akteur.Eine verschiedenfarbige Säule zeigt, dass die zugehörige Datei von unterschiedlichen

16


Abbildung 2.5: Chronia [62] – Aufbau einer so genannten Ownership Map

Abbildung 2.6: Chronia [62] – Visualisierung einer Ownership Map

Personen modifiziert wurde. Somit lassen sich Projektartefakte identifizieren, diemöglicherweise kooperativ erstellt wurden.

Mithilfe von Chronia [62] und so genannten Datei-Autor-Matrizes [72] lassen sichnützliche Informationen zur Beantwortung der sekundären Frage SF10 nach demgemeinsamen Quellcodeeigentum finden (siehe auch Abbildung 2.5, Abbildung 2.6und Abbildung 2.7). Ein gemeinsames Quellcodeeigentum legt nahe, dass die Arte-fakte in Zusammenarbeit entwickelt wurden. Ob es dabei in der Tat zu Interaktionbeziehungsweise Kooperation zwischen den Personen kam, kann mit den beidenProgrammen jedoch nicht abschließend festgestellt werden.

Storey et al. [68] untersuchten zahlreiche Programme zur Bewusstseinsbildungüber die Aktionen der Mitglieder eines Software-Projektteams: Seesoft, VRCS, Tukan,ADVIZOR, Xia/Creole, Palantír, Jazz, softChange, Evolution Matrix, Beagle, Spectro-graph und Augur. Im Hinblick auf den Einsatz im Rahmen einer Interaktionsanalyse

Abbildung 2.7: Datei-Autor-Matrix [72] – Die 𝑥-Achse bildet die Dateien, die 𝑦-Achse die Autoren ab. Die Anzahl der Änderungen wird farblichgekennzeichnet: Blau steht für wenige, Rot für viele Änderungen.

17


Abbildung 2.8: Augur [27] – Ansichten in der Übersicht

macht Augur [26, 27, 66] einen vielversprechenden Eindruck. Damit lassen sichder Artefaktquellcode sowie die Aktionen der Teammitglieder untersuchen. DasProgramm hebt zum einen die Verbindungen zwischen den Mitgliedern und demQuellcode hervor, zum anderen deckt es Beziehungen und Abhängigkeiten zwischenden einzelnen Angehörigen des Projektteams auf (siehe auch Abbildung 2.8). Augurhilft zwar bei der Beantwortung einiger sekundärer Fragen wie nach der Team-struktur (SF1), nach Untergruppen (SF2), der Gruppenhierarchie (SF3) und derAktivität einzelner Mitglieder (SF5), bleibt aber Antworten auf die primären Fragenweitgehend schuldig, ob Kooperation stattfand (PF1) und wie ausgeprägt sie war(PF2).

Der Einsatz von StarGate [48] (siehe Abbildung 2.9 auf der nächsten Seite) hilftdabei, das Beziehungsgeflecht zwischen Teammitgliedern zu verstehen. Leider benö-tigt das Programm zwei Datenquellen, sowohl das Softwarearchiv, das alle Artefakteund deren Entstehungsgeschichte enthält, als auch das Archiv der Mailingliste, dieder Gruppe zur Kommunikation dient. Insofern ist das Programm im Hinblick aufdie Anforderung, ausschließlich den Quellcode der Projektartefakte zu verarbeiten,von eingeschränktem Nutzen.

Alitheia ist eine Plattform zur automatisierten Evaluation von Softwareprojek-ten [31, 54]. Zwei Zusatzprogramme sind besonders interessant. Sie helfen, Antwortenauf die sekundären Fragen nach Untergruppen (SF2) und dem Vorgehens- bezie-hungsweise Prozessmodell (SF13) zu finden. Eines misst den Beitrag jedes einzelnenTeammitglieds zum Projekt [30]. Dabei kombiniert eine so genannte Beitragsfunktiondie bekannte Softwaremetrik Lines Of Code (LOC) mit einem Beitragsfaktor, wel-cher sich aus der Anzahl der als Projektbeiträge gewerteten Aktionen ergibt. Sowohldie verschiedenen Projektartefakte als auch die Aktionstypen werden im Hinblickauf die Relevanz für den Projektfortschritt unterschiedlich gewichtet. Anhand der

18


Abbildung 2.9: StarGate [48] – Kernentwickler (rot) stehen sowohl mit Mitgliedernder eigenen Gruppe als auch mit den anderer Gruppen in Beziehung,Mitglieder der peripheren Entwicklergruppe (grün) haben in ersterLinie Beziehungen zu den Kernentwicklern, innerhalb der Gruppeist das Beziehungsgeflecht dünn.

Beitragsfunktionswerte ließen sich die Gruppenmitglieder strukturieren. Ein hoherWert spräche dafür, dass ein Mitglied zur Untergruppe der Kernentwickler gehört.

Das andere Zusatzprogramm bestimmt mithilfe der Metrik Mean Developer En-gagement (MDE) [1], ob das Softwareprojekt gemäß eines agilen Vorgehensmodellsentwickelt wird. Agile Vorgehensweisen [14] implizieren ein hohes Maß an Kooperati-on zwischen den Mitgliedern der Entwicklergruppe. Sie zeichnen sich ferner dadurchaus, dass die Teammitglieder fest im Entwicklungsprozess eingebunden sind. Esmag unter den Mitgliedern zwar Unterschiede hinsichtlich der Produktivität geben,völlige Inaktivität ist jedoch mit einem agilen Prozessmodell nicht zu vereinbaren.Weniger fleißige Gruppenmitglieder würden den Fortschritt eines Projekts signifikanthemmen, das mit agilen Methoden entwickelt wird. Die Metrik MDE bestimmtdas Verhältnis der aktiven Personen zur Gesamtanzahl der Teamangehörigen. DasVerhältnis gibt die Effizienz wieder, mit der die Gruppenmitglieder eingesetzt werden.Aus den genannten Erwägungen folgt, dass ein hoher Zahlenwert ein Indiz für einagiles Prozessmodell ist. Je höher das Verhältnis, also je höher die Agilitätsstufe,desto intensiver müsste die Zusammenarbeit gewesen sein. Zusammenfassend for-muliert: Mit dem Einsatz von MDE lässt sich Kooperation bestenfalls indirekt undauch nur qualitativ ermitteln.

Alonso et al. [2] beschreiben so genannte Expertise Clouds zur Visualisierungvon Expertenwissen mithilfe von Schlagwortwolken8. Die dazu benötigten Datenextrahiert das von den Autoren entwickelte Programm aus dem von einer Versions-verwaltung gespeicherten Quellcode der geteilten Artefakte. Es lässt sich etwas über

8Englisch tag clouds.

19


Abbildung 2.10: Expertise Clouds [2] – Die Schriftgröße kennzeichnet das Wissen einerPerson. Je größer die Schrift, desto profunder sind die Kenntnisseauf dem zugehörigen Gebiet.

die Wissensgebiete und die Sachkenntnis der Entwickler des untersuchten FLOSS-Projekts in Erfahrung bringen (siehe auch Abbildung 2.10). Damit fällt es leichter,die sekundären Fragen SF8 und SF9 nach der Fachkenntnis von Personen (sieheTabelle 2.2 auf Seite 11) zu beantworten.

2.2.1 BewertungZusammenfassend ist festzustellen, dass die bereits vorhandenen Analysewerkzeuge,die den Quellcode der Projektartefakte beziehungsweise dessen Historie als Daten-quelle verwenden, zwar Hilfestellung zur Beantwortung der sekundären Fragestellungbieten, aber zu wenig Informationen zur ausreichenden Klärung der primären Fragenzu Tage fördern. Die Programme erfüllen in erster Linie die Belange von Personen,die auf den Feldern Softwaretechnik, -evolution, -archäologie oder Managementvon Softwareprojekten, aber nicht im Bereich rechnergestützte Zusammenarbeit(CSCW) tätig sind.

Wünschenswert ist ein Programm, das einen Zahlenwert für den jeweiligen Un-tersuchungsgegenstand präsentiert. Diese Maßzahl dient dann als Indikator fürKooperation und erleichtert damit die Suche nach Antworten auf die beiden pri-mären Fragen PF1 und PF2 (siehe Tabelle 2.1 auf Seite 9), ob und mit welcherIntensität Interaktion beziehungsweise Kooperation stattgefunden hat.

Tabelle 2.3 auf der nächsten Seite zeigt, inwiefern die vorgestellten Analysewerk-zeuge helfen, Antworten auf die in Tabelle 2.1 auf Seite 9 und Tabelle 2.2 auf Seite 11aufgeführten Fragen zu finden. In Vorgriff auf die kommenden Kapitel, fließt diespäter vorgestellte Erweiterung des Eclipse-Zusatzprogramms File History Flow mitin die Bewertung ein.

20


Tabelle 2.3: Bewertung der Analysewerkzeuge(+ : gut, ∘ : befriedigend, − : schlecht)

Bewertung der Analysewerkzeuge

Frag

e

File

Hist

ory

Flow

Code

Saw

Chro

nia

Dat

ei-Au

tor-M

atrix

Augu

r

Star

Gate

CVSC

heck

er

Bloo

f

Alith

eia

Expe

rtise

Clou

d

PF1 + + ∘ ∘ ∘ + ∘ − − −PF2 + ∘ − − − − − − − −SF1 − − − − + + − − − −SF2 ∘ − − − + + ∘ ∘ − −SF3 − − − − ∘ ∘ − − − −SF4 − − − − − − − − − −SF5 + + − − + ∘ + + + ∘aSF6 ∘ ∘ + + ∘ + ∘ − − −SF7 − + ∘ ∘ ∘ + − − − −SF8 ∘ ∘ − − ∘ + ∘ − − +SF9 ∘ ∘ − − ∘ + ∘ − − +SF10 ∘ ∘ ∘ ∘ ∘ − ∘ − − −SF11 − − − − − − − − + −SF12 + ∘ − − ∘ ∘ − − − −SF13 ∘ ∘ − − ∘ ∘ + ∘ + −

a Die Entwickleraktivität wird wolkenförmig dargestellt.

PF1: Fand Kooperation statt?PF2: Wie eng war die Kooperation?SF1: Wird die soziale Struktur des Projektteams sichtbar?SF2: Gibt es Untergruppen in Gestalt einer Kernentwicklergruppe und einer Gruppe von peri-

pheren Entwicklern?SF3: Existiert eine Hierarchie?SF4: Wie ist die Rollenverteilung ausgestaltet?SF5: Existieren Gruppenmitglieder, die aktiver sind als andere?SF6: Arbeitet ein Entwickler bevorzugt mit anderen zusammen oder zieht er Einzelarbeit vor?SF7: Ist zu beobachten, dass ein Gruppenmitglied häufiger mit bestimmten Entwicklern zusam-

menarbeitet?SF8: Sind Rückschlüsse auf das Expertenwissen der Teammitglieder möglich?SF9: Auf welchen Arbeitsfeldern tut sich ein Entwickler besonders hervor?SF10: Gibt es ein gemeinsames Quellcodeeigentum oder gehört der Quellcode demjenigen, der

ihn geschrieben hat?SF11: Sind Rückschlüsse auf ein (agiles) Vorgehensmodell möglich?SF12: Sind Trends in der Zusammenarbeit zu beobachten?SF13: Gibt es Alarmsignale, die auf einen drohenden Misserfolg des Projekts schließen lassen?

21


2.3 AnforderungenAls alleinige Datenquelle dient der von einem Versionsverwaltungssystem verwal-tete Quellcode der gemeinsamen Artefakte eines Softwareprojekts. Der Quellcodeliegt in Gestalt von Textdokumenten vor. Das zu entwickelnde Werkzeug – dasbisherige Eclipse-Plug-in File History Flow von Kästel-Baumgartner [39] bildetdas Grundgerüst – soll in der Lage sein, in beliebige Programmiersprachen ver-fasste Quellcodedateien zu verarbeiten. Dazu ist von der Programmiersprache zuabstrahieren. Das Plug-in soll generell in der Lage sein, einerseits artefaktbezogenesowie artefaktübergreifende, projektweite Kooperation in Projektteams zu erkennenund andererseits kooperativ erstellte Artefakte von denen zu unterscheiden, die inEinzelarbeit entstanden.

2.3.1 Funktionale AnforderungenGeht es um den Entwurf einer Anwendung zur Visualisierung von Informationen, sobietet die Taxonomie nach Shneiderman [65] eine hilfreiche Orientierung. Demnachsollten Übersichts- und Ausschnittsfunktionen, Funktionen zur Verkleinerung oderVergrößerung des Abbildungsmaßstabs (Zoom), zur Ausfilterung uninteressanterInformationen, zur Anforderung von Detailinformationen, zur Begrenzung des Un-tersuchungszeitraums und zur Verknüpfung von Informationen angeboten werden.Desweiteren müsste es möglich sein, die gewonnenen Resultate abzuspeichern. Fer-ner sollte der Benutzer die Möglichkeit haben, die zu untersuchenden Artefaktevorzugeben. Dazu ist eine Auswahlfunktion bereitzustellen.

Projektebene

Auf der Projektebene wird artefaktübergreifende Interaktion beziehungsweise Ko-operation betrachtet. Dazu muss die erweiterte Version des Plug-ins in der Lage sein,zu erkennen, ob eine von einem Teammitglied ausgeführte Aktion eine Reaktion aufeine der vorangegangenen eines anderen Mitglieds ist, welche sich auf ein anderesArtefakt bezieht. Auf Grundlage der vom Benutzer ausgewählten Artefakte solldas Plug-in Interaktionswerte für bestimmte Zeitabschnitte ihrer Entstehungsge-schichte berechnen, die als Maßzahlen für die Intensität des Zusammenwirkens derAkteure dienen. Die einzelnen Messwerte sind entlang einer Zeitachse anzuordnen.Zur Darstellung soll eine Diagrammform gewählt werden, die es dem Benutzerermöglicht, den jeweiligen Zahlenwert und das zugehörige Datum unmittelbar ab-zulesen. Zusätzlich soll es möglich sein, einen Wechsel zur Sicht auf Dateiebenedurchzuführen und dann dort jene Artefakte zu untersuchen, auf denen sich dieprojektweite Interaktion während eines bestimmten Zeitraums erstreckte. Auf dieseWeise soll sich ermitteln lassen, ob die Artefakte nicht nur in projektweiter, sondernauch in artefaktbezogener Kooperation bearbeitet wurden.

22

2.3 Anforderungen

Dateiebene

Das erweiterte Plug-in soll die geteilten Projektartefakte ähnlich wie die Grundversi-on des Plug-ins grafisch visualisieren. Abbildung 3.6 auf Seite 36 veranschaulicht dieKonzeption. Es bietet sich an, die Artefakte säulenförmig entlang einer Zeitachsedarzustellen. Die Länge der Säulen soll die Lebensdauer der Artefakte wiedergeben.Kooperativ produzierte Artefakte sind anders einzufärben als diejenigen, die inEinzelarbeit erstellt wurden. Phasen der Entstehungsgeschichte eines kooperativentstandenen Artefakts, die sich durch eine unterschiedliche Intensität des Zu-sammenwirkens zwischen den Mitgliedern des Projektteams unterscheiden, sindverschiedenfarbig darzustellen. Dazu sind die Säulen zu segmentieren. Jedes Segmentrepräsentiert eine bestimmte Phase der Entstehungsgeschichte. Dem Benutzer sindverschiedene Funktionen zur Sortierung der dargestellten Artefakte zur Verfügungzu stellen. Es soll möglich sein, die Artefakte anhand der Intensität der Interaktion,mit der sie entstanden sind, anzuordnen.

2.3.2 Technische AnforderungenAls Versionsverwaltungssystem wird das Concurrent Versions System (CVS) vor-ausgesetzt. Andere Systeme brauchen nicht berücksichtigt zu werden. Falls daszu entwickelnde Werkzeug Daten in Form von Rastergrafiken exportiert, dann istmöglichst ein standardisiertes, plattformübergreifendes Grafikformat zu wählen, zumBeispiel Portable Network Graphics (PNG). Für den Export von Daten in Textformist ein Datenformat zu benutzen, das sich auf die Extensible Markup Language(XML) stützt.

Es soll von der Programmiersprache abstrahiert werden, in die der Quellcodeder gemeinsamen Artefakte verfasst wurde. Die Art und Weise der Verarbeitungdes Inhalts der Quellcodedateien soll für alle Programmiersprachen gleich sein. DieBedeutung des Inhalts der Dateien ist demzufolge irrelevant. Die Quellcodedateiensind wie gewöhnliche Textdateien zu behandeln.

Zum Persistieren der Entstehungsgeschichte der untersuchten Projektartefakteverwendet das ursprüngliche Eclipse-Plug-in File History Flow eine vom relationalenDatenbankverwaltungssystem MySQL9 verwaltete Datenbank10. Die zu program-mierende Plug-in-Erweiterung soll diese Datenbank verwenden und gegebenenfallserweitern oder modifizieren.

2.3.3 Anforderungen im ÜberblickTabelle 2.4 auf der nächsten Seite bietet eine Übersicht der funktionalen undtechnischen Anforderungen (FA, TA).

9Siehe http://www.mysql.com10Im Prinzip kann ein beliebiges Datenbankmanagementsystem eingesetzt werden, auf das sich

per Schnittstelle Java Database Connectivity (JDBC) zugreifen lässt.

23

http://www.mysql.com


Tabelle 2.4: Anforderungen im Überblick

Anforderungen

Nr. Analyseebene AnforderungTA1 Weiterentwicklung des Plug-ins File History Flow.TA2 Datenquelle: Quellcode der gemeinsamen Artefakte.TA3 Anbindung an das Versionsverwaltungssystem CVS.TA4 Abstraktion von der Programmiersprache, in die

der Quellcode vorliegt.TA5 Benutzung einer lokalen Datenbank zur Persistierung.FA1 Funktion zur Selektion der zu analysierenden Artefakte.FA2 Bereitstellung von Übersichts- und Ausschnittsfunktionen.FA3 Entwicklung einer Zoomfunktion.FA4 Implementierung eines Filters.FA5 Anbieten von Detailinformationen.FA6 Speicherung der Ergebnisse in Form von Rastergrafiken

und/oder XML-Dokumenten.FA7 Projektebene Import von XML-Dokumenten.FA8 Dateiebene Identifizierung und Auszeichnung kooperativ produzierter

Artefakte.FA9 Projektebene Detektion projektweiter, artefaktübergreifender

Zusammenarbeit und Berechnung der Intensität.FA10 Anordnung der Messwerte entlang einer Zeitachse,

Dateiebene und zwar zeilen- oder spaltenweise oder durchProjektebene Wahl einer geeigneten Diagrammform

(zum Beispiel Säulendiagramm).FA11 Dateiebene Farbe als Informationsträger. Kooperativ erstellte

Artefakte sind andersfarbig darzustellen, alsindividuell produzierte.

FA12 Dateiebene Bereitstellung von Sortierungsfunktionen.FA13 Projektebene Fortsetzung unterbrochener Berechnungen (optional).

24

3 LösungsansatzDieses Kapitel beschäftigt sich zunächst mit den mathematischen Grundlagen zurBerechnung von Interaktionswerten. Anschließend werden Aspekte der Datengewin-nung auf Basis der Entstehungsgeschichte des Quellcodes eines Softwareprojektsbetrachtet. Der Schlussteil erläutert Lösungsansätze zur grafischen Visualisierungvon sozialer Interaktion.

3.1 Berechnung von Interaktionswerten3.1.1 Eigenschaften kooperativ erstellter ArtefakteDie nachfolgenden Abschnitte stellen eine Metrik vor, die sich als Maß für einebestimmte Eigenschaft von Projekten beziehungsweise Projektartefakten eignet.Sie bildet diese Eigenschaft auf einen Zahlenwert (Maßzahl) ab, und zwar aufden so genannten Interaktionswert. Der Interaktionswert schafft die Möglichkeitzur Bewertung, ob und in welchem Grad Projektartefakte kooperativ produziertwurden. Kooperativ erstellte Artefakte weisen einen hohen Interaktionswert alsQualitätsmerkmal auf, während sich individuell, in Einzelarbeit entstandene durcheinen niedrigen Wert auszeichnen. Somit lassen sich geteilte Artefakte miteinandervergleichen.

3.1.2 Grundlagen der Bewertung von InteraktionSchümmer et al. [61] beschreiben eine elegante Methode zur Bewertung von Inter-aktion zwischen Lernenden. Protokolldateien von kooperativen Systemen zeichnendie Tätigkeiten der Benutzer auf. Die genannten Autoren verwenden diese Pro-tokolldateien1 als Datenquelle für ihre Analysen. Kernbestandteil der Methodeist eine Metrik, die auf einem räumlich-zeitlichen Modell beruht. Mithilfe dieserMetrik können Aktionen der Handlungspartner erfasst werden, die räumlich oderzeitlich nah beieinander stehen. Diese Aktionen werden als Ausdruck von Interak-tion betrachtet, denn eine räumlich-zeitliche Nähe lässt darauf schließen, dass dieHandlungen aufeinander bezogen und die Voraussetzungen für das Vorliegen sozialerInteraktion erfüllt sind. Ein Interaktionswert bildet die Interaktionsstärke ab.

Die Autoren gehen davon aus, dass räumlich benachbarte Aktionen mit hoherWahrscheinlichkeit logisch beziehungsweise semantisch miteinander verbunden sind.Die Motivation hinter dieser Annahme ist mutmaßlich praktischer Natur. Eine

1Englisch log files.

25

3 Lösungsansatz

Inhaltsanalyse beziehungsweise eine Analyse der Interaktionskopplung anhand vonAufruf- oder Abhängigkeitsgraphen wäre mit erheblichem Aufwand verbunden. Wiekann die räumliche Distanz zwischen zwei Aktionen gemessen werden? Die Autorenregen an, die Artefakte, die Gegenstand der Handlungen sind, im Hinblick auf ihrePositionen im gemeinsamen Arbeitsbereich miteinander zu vergleichen. Als konkretesVergleichskriterium kommen Pfade im Dateisystem in Betracht. Je kürzer die Längedes Pfades zwischen zwei Artefakten ist, desto geringer ist die räumliche Distanzund desto stärker sind die betrachteten Aktionen logisch aufeinander bezogen. DieseMessmethode implementiert gewissermaßen das Entwurfsmuster2 Semantic Distancenach Schümmer et al. [57–60].

Eine Tätigkeit kann als eine Reaktion auf eine andere gelten, wenn neben demlogischen auch ein zeitlicher Bezug existiert. Je größer der zeitliche Abstand zwischenzwei Aktionen ist, desto unwahrscheinlicher ist es, dass die jüngere Aktion eineReaktion auf die ältere ist, dass die beiden Aktionen zu einem kausalen Ereignisgehören.

Es lässt sich das folgende heuristische Prinzip ableiten: Je zeitnäher die Aktionenerfolgen und je näher die gemeinsamen Artefakte beieinander stehen, auf die sichdie Aktionen beziehen, desto intensiver ist die Interaktion zwischen den Akteurengewesen.

Die oben genannten Autoren betrachten jeweils Aktionspaare, zusammengesetztaus der Aktion einer Person und der Reaktion des Handlungspartners. Nur Aktions-paare, die einen positiven Interaktionswert aufweisen, werden bei der Berechnungdes Interaktionsgrads3 beziehungsweise des Gruppeninteraktionswerts berücksich-tigt. Diese Kennzahl dient als Maß für die Stärke der Interaktion zwischen denHandlungspartnern. Sie ermöglicht die Bewertung von Interaktion in Gruppen.

3.1.3 Formel zur Berechnung von InteraktionswertenDer im Folgenden erwähnten Methode zur Berechnung von Interaktionswertenliegt eine Schümmer et al. [61] entlehnte Formel zugrunde. Der akkumulierteInteraktionswert 𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥) für die Zeitspanne [𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥] ist die Summe derInteraktionswerte von Aktionspaaren (𝑎𝑖, 𝑎𝑗), die einen Interaktionswert 𝑖𝑎(𝑎𝑖, 𝑎𝑗) >0 aufweisen, dividiert durch die Anzahl 𝑚 dieser Aktionspaare. Die Aktionen 𝑎𝑖und 𝑎𝑗 müssen Elemente der Menge 𝐴 = {𝑎0, 𝑎1, . . . , 𝑎𝑛} aller Aktionen sein und

2Englisch design pattern.3Bei diesem Gesamtinteraktionswert für die Menge aller erfassten Aktionen handelt sich im

Grunde genommen um einen Durchschnittswert.

26

3.1 Berechnung von Interaktionswerten

von verschiedenen Akteuren stammen (𝑢𝑎𝑖 ̸= 𝑢𝑎𝑗). Dabei ist Aktion 𝑎𝑖 stets eineReaktion auf 𝑎𝑗, sodass für die Zeitpunkte der Aktionen 𝑡𝑎𝑖 ≥ 𝑡𝑎𝑗 gilt.

𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑡𝑎𝑖≥𝑡𝑎𝑗

𝑡𝑚𝑖𝑛≤𝑡𝑎𝑗 , 𝑡𝑎𝑖≤𝑡𝑚𝑎𝑥𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑖𝑎(𝑎𝑖,𝑎𝑗)>0

𝑖𝑎(𝑎𝑖, 𝑎𝑗)𝑘 (3.1)

Die Intensität beziehungsweise Stärke der Interaktion zwischen zwei Aktionen 𝑎𝑖und 𝑎𝑗 entspricht der Länge eines in den Dimensionen Zeit und Raum gegebenenzweidimensionalen Vektors

𝑖𝑎(𝑎𝑖, 𝑎𝑗) =⃒⃒⃒⃒⃒⃒(︃𝑛𝑑𝑡(𝑎𝑖, 𝑎𝑗, 𝑑𝑡𝑚𝑎𝑥)𝑛𝑑𝑠(𝑎𝑖, 𝑎𝑗, 𝑑𝑠𝑚𝑎𝑥)

)︃⃒⃒⃒⃒⃒⃒ =

√︁𝑛𝑑𝑡(𝑎𝑖, 𝑎𝑗, 𝑑𝑡𝑚𝑎𝑥)2 + 𝑛𝑑𝑠(𝑎𝑖, 𝑎𝑗, 𝑑𝑠𝑚𝑎𝑥)2

mit der normalisierten zeitlichen Distanz

𝑛𝑑𝑡(𝑎𝑖, 𝑎𝑗, 𝑑𝑡𝑚𝑎𝑥) = 𝑚𝑎𝑥𝑛𝑜𝑟𝑚 ·𝑚𝑎𝑥⎧⎨⎩0, 𝑑𝑡𝑚𝑎𝑥 − 𝑑𝑡(𝑎𝑖, 𝑎𝑗)

𝑑𝑡𝑚𝑎𝑥

⎫⎬⎭und der normalisierten räumlichen Distanz

𝑛𝑑𝑠(𝑎𝑖, 𝑎𝑗, 𝑑𝑠𝑚𝑎𝑥) = 𝑚𝑎𝑥𝑛𝑜𝑟𝑚 ·𝑚𝑎𝑥⎧⎨⎩0, 𝑑𝑠𝑚𝑎𝑥 − 𝑑𝑠(𝑎𝑖, 𝑎𝑗)

𝑑𝑠𝑚𝑎𝑥

⎫⎬⎭.

Die Werte der normalisierten Distanzen liegen im Bereich zwischen 0 und𝑚𝑎𝑥𝑛𝑜𝑟𝑚,wobei 𝑚𝑎𝑥𝑛𝑜𝑟𝑚 ≥ 1 gilt. Beträgt 𝑚𝑎𝑥𝑛𝑜𝑟𝑚 gleich 1, so liegt der Interaktionswert𝑖𝑎(𝑎𝑖, 𝑎𝑗) im Wertebereich zwischen 0 und abgerundet 1,41 ≈

√12 + 12. Die Norma-

lisierung dient dazu, Interaktionswerte mit unterschiedlicher Grundlage vergleichbarzu machen. Durch die Skalierung des Wertebereichs auf einen bestimmten Bereichlassen sich Interaktionswerte miteinander vergleichen, die für verschiedene Projekteberechnet wurden.

Die Modifikation eines Quellcodeblocks entspricht einer Aktion, die von einemGruppenmitglied ausgeführt wurde. Die Grundversion des Eclipse-Plug-ins FileHistory Flow bildet die Aktionen auf Eclipse-Annotationen ab. Zur Berechnung einesInteraktionswerts prüft das weiterentwickelte Plug-in anhand dieser Annotationen,ob jeweils zwei Aktionen der Handlungspartner aufeinander bezogen waren, indem esdie räumlich-zeitliche Distanz misst. Fällt die Prüfung positiv aus, ist der Abstandzwischen den Aktionen nicht größer als die räumliche oder zeitliche Maximaldistanz(𝑑𝑠𝑚𝑎𝑥, 𝑑𝑡𝑚𝑎𝑥), dann fließen die beiden Aktionen in Form eines Aktionspaares in dieoben geschilderte Interaktionswertberechnung ein.

27

3 Lösungsansatz

Messung der zeitlichen und räumlichen Distanz

Die eingangs erwähnte Methode zur Messung von Interaktion kombiniert die zeitlicheDistanz 𝑑𝑡(𝑎𝑖, 𝑎𝑗) = 𝑡𝑎𝑖 − 𝑡𝑎𝑗 mit der räumlichen Distanz 𝑑𝑠(𝑎𝑖, 𝑎𝑗), wobei dieVariablen 𝑡𝑎𝑖 und 𝑡𝑎𝑗 die Zeitstempel der Aktionen 𝑎𝑖 und 𝑎𝑗 sind. Es gilt: Jekürzer der Zeitabstand zwischen den Aktionen, desto größer der korrespondierendeInteraktionswert.

Die Definition der Funktion 𝑑𝑠(𝑎𝑖, 𝑎𝑗) hängt vom jeweiligen räumlichen Modell ab.Soll Interaktion betrachtet werden, die sich auf einzelne Artefakte – beispielsweiseQuelltextdateien – bezieht, dann kann die räumliche Distanz die Anzahl der Textzei-len sein, die sich zwischen den Blöcken befinden, welche durch die beiden Aktionen𝑎𝑖 und 𝑎𝑗 modifiziert wurden. Hierbei kommt ein relatives Maß zum Einsatz. Dermaximale Abstand wird in Prozent der Länge der jeweiligen Datei (in Anzahl derTextzeilen) angegeben. Beispiel: Ist 𝑑𝑠𝑚𝑎𝑥 = 15 % und die Datei 100 Zeilen lang, sobeträgt die konkrete räumliche Maximaldistanz 15 Zeilen. Falls die Datei hingegen60 Zeilen lang ist, dann beträgt die effektive Maximaldistanz 9 Zeilen. Je kürzerder räumliche Abstand zwischen jeweils zwei von unterschiedlichen Personen modifi-zierten Quellcodeblöcken, desto höher ist die logische beziehungsweise semantischeKopplung zwischen den zugehörigen Handlungen, desto größer ist der resultierendeInteraktionswert und desto größer ist die Wahrscheinlichkeit, dass das HandelnAusdruck von Kooperation ist.

Wird artefaktübergreifende Interaktion untersucht, so schlagen Schümmer etal. in [61] vor, die räumliche Distanz zwischen zwei Aktionen 𝑎𝑖 und 𝑎𝑗, die zueiner Veränderung unterschiedlicher Artefakte führten, als Länge des kürzestenDateisystempfades zwischen den Artefakten wiederzugeben. Wie bereits geschildert,spiegelt der räumliche Abstand die semantische Distanz zwischen zwei Aktionenwider. Je kürzer die räumliche Distanz, desto stärker sind die beiden Aktioneninhaltlich beziehungsweise logisch aufeinander bezogen.

Kalibrierung

Vor jedem Einsatz der Formel (3.1) muss eine Kalibrierung durch die Wahl geeig-neter Werte für die Grenzwerte 𝑑𝑡𝑚𝑎𝑥 und 𝑑𝑠𝑚𝑎𝑥 durchgeführt werden (vgl. [61]).Die Werte hängen zum einen von der Struktur des Untersuchungsgegenstands undzum anderen von der Form der Interaktion ab. Für ein komplexes FLOSS-Projekt,dessen Artefakte in zahlreichen Paketen oder Modulen organisiert sind, kann imKontext der Bewertung projektweiter Interaktion beispielsweise ein Wert von 3 fürdie räumliche Maximaldistanz 𝑑𝑠𝑚𝑎𝑥 gewählt werden. Die Mitglieder eines weltweitverteilten FLOSS-Projektteams interagieren in der Regel asynchron und unregelmä-ßig miteinander. Deshalb sollte die zeitliche Maximaldistanz 𝑑𝑡𝑚𝑎𝑥 einen Wert vonmehreren Tagen aufweisen (zum Beispiel 7). Für die Wahl geeigneter Grenzwerte be-nötigt der Benutzer des Eclipse-Zusatzprogramms etwas Fingerspitzengefühl. Dabeikann die Strategie Versuch und Irrtum hilfreich sein. Die Grenzwerte werden solange

28

3.1 Berechnung von Interaktionswerten

variiert, bis die Messungen Ergebnisse zu Tage fördern, die plausibel erscheinen.Dabei bietet sich die folgende Faustregel an:

• Je höher die Frequenz der Aktionen, die zu Änderungen im Repository desVersionsverwaltungssystems führen, desto kürzer kann die zeitliche Maximal-distanz 𝑑𝑡𝑚𝑎𝑥 ausfallen.

• Je komplexer die baumartige Struktur der Verzeichnisse ist, in denen sich diegeteilten Artefakte befinden, je größer der Abstand zwischen je zwei Artefaktensein kann, desto größer darf die räumliche Maximaldistanz 𝑑𝑠𝑚𝑎𝑥 sein.

Abschnitt 6.2 auf Seite 68 geht auf Probleme ein, die sich aus der Wahl unpassenderGrenzwerte ergeben können.

3.1.4 Ebenen der InteraktionsanalyseDie geteilten Artefakte eines Projekts können auf zwei Ebenen untersucht werden4.

Analyse auf Projektebene: Die Interaktionsanalyse über alle Artefakte hinwegdient letztlich zum Erkennen und zur Bewertung artefaktübergreifender Ko-operation. Ein Aktionspaar setzt sich aus einer Aktion, die zu einer Änderungeines Artefakts führte, und aus einer Folgeaktion eines anderen Teammitgliedszusammen, die sich auf ein anderes Artefakt bezieht. Die einzelnen Aktions-paare bilden die Grundlage für die in Abschnitt 3.1 auf Seite 25 erläutertenBerechnung des Interaktionswerts. Abschnitt 4.1.1 auf Seite 39 schildert ver-schiedene Metriken, die die Eigenschaft eines Projekts bewerten, inwieweites kooperativ oder individuell produziert wurde. Formel (3.1) dient diesenMetriken als Grundlage.

Analyse auf Dateiebene: Die Interaktionsanalyse innerhalb der Grenzen eines Ar-tefakts soll artefaktbezogene Kooperation aufspüren. Aktionen, durch die eineder Vorgängerversionen des Artefakts entstand, verursachen möglicherweiseFolgeaktionen anderer Gruppenmitglieder, die zu einer neuen Version führen.Jeweils zwei aufeinander bezogene Aktionen bilden ein Aktionspaar und flie-ßen in die Interaktionswertberechnung ein. Infolgedessen weisen kooperativproduzierte Artefakte einen höheren Interaktionswert auf als diejenigen, die inEinzelarbeit erstellt wurden. Abschnitt 4.1.2 auf Seite 43 stellt die Metrikendieser Analyseebene vor.

Es wurde bereits erwähnt, dass eine Aktion der Modifikation eines Blocks imArtefaktquellcode entspricht.

4Siehe Anforderungen FA8 und FA9.

29

3 Lösungsansatz

3.2 DatengewinnungDie im Zuge dieser Abschlussarbeit entwickelte Erweiterung des Eclipse-Plug-insFile History Flow [39] verarbeitet Daten, die die Grundversion des Plug-ins erzeugt5.Diese adaptiert das CVS-Annotationsmodell und erzeugt Annotationen, die vonEclipse zur Anzeige gebracht werden können. Für jede im CVS-System aufgezeichne-te Änderung eines Blocks im Quellcode eines geteilten Software-Projektartefaktsexistiert eine Eclipse-Annotation. Die Änderung eines Quellcodeblocks entsprichteiner Aktion eines Mitglieds des Projektteams. Mit anderen Worten, dem Plug-insind alle Aktionen der Akteure bekannt. Es kennt die Entstehungs- beziehungsweiseEntwicklungsgeschichte jedes Artefakts. Der Benutzer des Plug-ins kann ermit-teln, welche Person ein Projektartefakt an welcher Stelle und in welchem Umfangmodifizierte. Außerdem kann er feststellen, zu welcher Zeit die Änderungen imVersionsverwaltungssystem abgespeichert wurden.

Quellcodedateien werden einheitlich als Textdateien behandelt. Für das Plug-inspielt es keine Rolle, in welcher Programmiersprache der Quellcode abgefasst ist.Das Programm ist in dieser Hinsicht universell einsetzbar und nicht auf bestimmteTypen von Softwareprojekten festgelegt.

Die Daten, anhand derer die Annotationen erzeugt werden, werden auf Wunschdes Benutzers in einer Datenbank abgelegt. Auf jene Datenbank greift das erweitertePlug-in zurück6. Das Programm erzeugt die benötigten Daten nicht stets aufs Neue.Vielmehr versucht es zuerst, sie aus der Datenbank einzulesen.

3.2.1 ProjektebeneAuf dieser Ebene werden zur Berechnung eines projektweiten, artefaktübergreifendenGruppeninteraktionswertes die folgenden Daten benötigt, und zwar für jede einzelneAktion:

• Zeitstempel der Aktion

• eindeutige Benutzerkennung des Urhebers der Aktion

• Name des Projekts

• Pfadname des gemeinsamen Artefakts

Das erweiterte Programm extrahiert die erforderlichen Daten mit einer Reihevon SQL-Abfragen aus der Datenbank und erzeugt dann eine Datenstruktur, diegewissermaßen eine Protokolldatei nachgebildet. Ein Eintrag in dieser Datenstruktursetzt sich aus den oben genannten Angaben zusammen. Er bildet eine von einemGruppenmitglied ausgeführte Aktion ab. Anhand dieser virtuellen Protokolldatei

5Siehe Anforderung TA1.6Siehe Anforderungen TA2, TA3, TA4 und TA5.

30

3.3 Visualisierung von sozialer Interaktion

werden dann die Interaktionswerte mit den von Schümmer et al. in [61] vorgeschla-genen Methoden zur Analyse von Protokolldateien7 bestimmt. Die Abschnitte 3.1auf Seite 25 und 4.1 auf Seite 39 erläutern das Verfahren.

3.2.2 DateiebeneAuf der Dateiebene wird für jede Version eines Artefakts ein Interaktionswert berech-net. Abschnitt 4.1 auf Seite 39 befasst sich mit den auf dieser Ebene angesiedeltenMetriken. Kernbestandteil des in Abschnitt 3.1 auf Seite 25 beschriebenen Ansatzesist die Messung der räumlich-zeitlichen Distanz zwischen jeweils zwei Aktionen.Dazu müssen die folgenden Daten vorliegen:

• Zeitstempel einer Aktion

• eindeutige Benutzerkennung des Urhebers einer Aktion

• Name des Projekts

• Pfadname des gemeinsamen Artefakts

• Nummern der im Artefaktquellcode modifizierten Textzeilen

Die Datenbank enthält diese Daten. Also muss das weiterentwickelte Plug-in keinezusätzlichen Funktionen zur Datengewinnung bereitstellen.

3.3 Visualisierung von sozialer InteraktionZu Beginn des Abschnitts 2.2 auf Seite 13 werden beiläufig einige Werkzeuge zurInteraktionsanalyse erwähnt, die ungeeignet sind, ein beliebiges Softwareprojektanhand seines Quellcodes zu untersuchen. Immerhin bieten sie Anregungen zurVisualisierung von sozialer Interaktion. Bevor der Ansatz zur Umsetzung der inAbschnitt 2.3.1 auf Seite 22 aufgeführten Anforderung nach der Darstellung vonartefaktbezogener sowie projektweiter sozialer Interaktion erläutert wird, werdeneinige Darstellungsbeispiele vorgestellt.

3.3.1 MusterbeispieleAbbildung 3.1 auf der nächsten Seite zeigt iTree [46], ein Programm, das anhand desWachstums eines Baumes darstellt, wie stark sich ein Teilnehmer in den Gruppen-prozess einbringt. Jedes Gruppenmitglied erhält seinen eigenen Baum. Die Beiträgedes Baumbesitzers fördern das Wachstum des Baumstamms. Je öfter die Beiträgevon den anderen Teilnehmern wahrgenommen werden, desto mehr Zweige undgrüne Blätter sprießen hervor. Die Anzahl der roten Früchte, die der Baum trägt,korrespondiert mit der Anzahl der Reaktionen auf die diskursfördernden Beiträge

7Englisch log file analysis.

31

3 Lösungsansatz

Abbildung 3.1: iTree [46] – Je stärker sich ein Teilnehmer in den Gruppenprozesseinbringt, desto besser gedeiht sein Baum.

Abbildung 3.2: K3-Gratifikationssystem [64] – Die Darstellung des Kollaborations-grads KG – ein Quadrupel aus Synthesegrad SG, Unabhängigkeits-grad UG, Interaktionsgrad IG und Teilnahmegrad TG – in Formeines vierachsigen Netzdiagramms.

des Baumbesitzers. Die Intensität der Blaufärbung des Himmels symbolisiert denAnteil des Teilnehmenden an der Anzahl der Beiträgen aller Teilnehmer. Ist derAnteil hoch, dann ist der Himmel tiefblau gefärbt.

In Abbildung 3.2 ist ein Diagramm zu sehen, das vom Gratifikationssystem [64]für das kollaborative Wissensmanagementsystem K3 erzeugt wurde. Das Grati-fikationssystem soll die Motivation zur Teilnahme an kollaborativen Prozessenverstärken. Dies geschieht durch Feedback über die erbrachten Leistungen mithilfeder Visualisierung bestimmter Leistungsmerkmale des teilnehmenden Akteurs. Dar-unter fällt die Kennzahl Interaktionsgrad. Eine mögliche Visualisierungsform ist dasNetzdiagramm.

Das Discussion Interaction Analysis System (DIAS) [11] stellt die Aktivität derAkteure in Form eines Polardiagramms dar. Es ist in Abbildung 3.3 auf der nächstenSeite zu sehen. Jedem Mitwirkenden wird eine eigene Kreisbahn zugeordnet. Auf ihrbefindet sich eine Kugel, deren Größe wiedergibt, wie viele verschiedene Nachrich-tentypen8 der Teilnehmer benutzt hat. Der Abstand vom Umkreis ist proportionalzum Teilnahmegrad.

8Die Nachrichtentypen können vom DIAS-Administrator definiert werden.

32


Abbildung 3.3: DIAS [11] – Der Abstand einer Kreisbahn vom Umkreis des Polar-diagramms ist proportional zum Teilnahmegrad des Mitwirkenden.

Abbildung 3.4 auf der nächsten Seite stellt mehrere Formen der Visualisierungvon Kennzahlen zur Quantifizierung von Zusammenarbeit vor. Darunter befindensich Kuchen-, Säulen- und Kurvendiagramme. Die gezeigten Musterbeispiele dienenlediglich als Anregungen zur Visualisierung von sozialer Interaktion.

Eine Übersicht weiterer Beispiele zur Visualisierung von sozialer Interaktionbietet [21].

3.3.2 ProjektebeneAuf der Projektebene wird artefaktübergreifende, projektweite Interaktion unter-sucht. Für bestimmte Zeitabschnitte der Entstehungsgeschichte des Projekts be-stimmt das weiterentwickelte Eclipse-Plug-in auf Grundlage der vom Benutzerausgewählten Projektartefakte beziehungsweise Dateien die Intensität der Grup-peninteraktion. Wiederum kommt das in in Abschnitt 3.1 auf Seite 25 erläuterteVerfahren zur Interaktionswertberechnung zum Einsatz, mit dem Unterschied, dassjeweils zwei aufeinander bezogene Aktionen auf unterschiedliche Artefakte ausge-führt werden müssen. Im Kontext projektweiter Interaktion kann eine Aktion nurdann als Auslöser einer Folgeaktion in Betracht kommen, wenn sie sich auf einanderes Artefakt bezieht als die Reaktion.

Die für die Zeitabschnitte gewonnenen Messwerte werden entlang einer Zeitachseangeordnet. Laut den in Abschnitt 2.3.1 auf Seite 22 formulierten Anforderungen sinddie Interaktionswerte in einer Form darzustellen, die es dem Benutzer erlaubt, dennumerischen Wert ohne Umwege ablesen zu können. Messungen erfolgen prinzipiellin unregelmäßigen Abständen, und zwar nachdem die Gruppenmitglieder ihre

33

3 Lösungsansatz

Abbildung 3.4: Musterbeispiele verschiedener Darstellungsformen: Kuchen-, Säulen-und Kurvendiagramme (aus [19, 24]). Sie bieten Anregungen zurVisualisierung sozialer Interaktion.

Project-wide Interaction Across Files

03.08.08

04.08.08

12.08.08

14.08.08

15.08.08

18.08.08

20.08.08

Date (TZ "UTC")

0

10

20

30

Me

tric

Va

lue

Durchschnitt: 9

Interaktion

Abbildung 3.5: Konzeptionsdiagramm – Visualisierung projektweiter Interaktion

34


Modifikationen an den gemeinsamen Artefakten im Versionsverwaltungssystemabgelegt haben. In der Zwischenzeit liegen keine Größen vor, die gemessen werdenkönnten. Es entstehen unter Umständen Lücken. Die Darstellungsform muss dieserBedingung Rechnung tragen. Demzufolge ist das Säulendiagramm ein geeigneterDiagrammtyp zur Veranschaulichung von Gruppeninteraktion. Jede Säule gibtfür eine bestimmte Zeitspanne die Höhe des gemessenen Interaktionswerts wieder.Abbildung 3.5 auf der vorherigen Seite zeigt ein Musterbeispiel. Die Eignung istferner aus dem Grunde gegeben, weil Diagramme dieses Typs sofort Antworten aufdie in Tabelle 2.1 auf Seite 9 aufgelisteten primären Fragen nach dem Vorliegen undder Ausprägung von Kooperation (PF1 und PF2) liefern.

Ausgehend von jeder Säule des Säulendiagramms kann ein Wechsel zur Sicht aufDateiebene erfolgen. Dort werden die Dateien dargestellt, die der betreffenden Säulezugeordnet sind. Abschnitt 3.3.3 schildert den Ansatz zur Interaktionsvisualisierungauf Dateiebene. Der Benutzer erhält die Möglichkeit, festzustellen, ob die Dateiennicht nur projektweit, sondern auch dateibezogen gemeinsam bearbeitet wurden.

3.3.3 DateiebeneDamit es nicht zu Brüchen im Hinblick auf die Visualisierung kommt, orientiert sichdie Form der Darstellung von sozialer Interaktion auf Dateiebene zum einen an dasursprüngliche Eclipse-Plug-in File History Flow [39]. Es verwendet eine säulenförmigeStruktur zur Visualisierung der Entstehungsgeschichte einer Datei. Abbildung 3.6auf der nächsten Seite zeigt den Aufbau eines entsprechenden Diagramms. DieseGrundform der visuellen Darstellung wird im erweiterten Plug-in beibehalten. Zumanderen dient das in Abbildung 2.1 auf Seite 14 dargestellte Programm CVSGrab [71]als Vorbild für die Art und Weise der Visualisierung.

Das im Rahmen dieser Abschlussarbeit weiterentwickelte Programm bestimmtfür jede Version eines geteilten Artefakts9 einen Kennzahlenwert, der die Stärke derZusammenarbeit zwischen jenen Entwicklern anzeigt, die das Artefakt bearbeitethaben. Das geschieht auf Grundlage des in Abschnitt 3.1 auf Seite 25 erwähntenInteraktionswerts, der als Indikator für Kooperation dient (siehe 2.1.2 auf Seite 8).Bei der Berechnung des artefaktbezogenen Interaktionswertes werden nicht alleAktionen der Gruppenmitglieder berücksichtigt, sondern nur diejenigen, die aufdemselben Artefakt ausgeführt wurden.

Das erweiterte Plug-in stellt eine einzelne Datei – ein einzelnes geteiltes Artefakt –in Form einer Säule entlang eines vertikal verlaufenden Zeitstrahls dar10. DieseSäule ist in Segmente unterteilt. Jedes repräsentiert eine Version der Datei. DieSegmentlänge ist proportional zur Lebensdauer der zugehörigen Dateiversion. DieFarbe der Segmente dient als Informationsträger11. Sie korrespondiert mit dem Inter-aktionswert, der auf Grundlage der Tätigkeiten berechnet wird, die zur Entstehung

9Im Falle eines quelloffenen Softwareprojekts wird es sich dabei gewöhnlich um eine Textdateihandeln, die den Quellcode des Artefakts enthält.

10Siehe Anforderung FA10.11Siehe Anforderung FA11.

35

3 Lösungsansatz

Abbildung 3.6: File History Flow [39] – Ein säulenförmiges Diagramm zur Darstellungder Entstehungsgeschichte einer Datei. Jede Säule repräsentiert eineDateiversion.

der zugehörigen Dateiversion führten. Dieser Ansatz greift Tuftes [70] Vorschlagauf, Farbe zur Darstellung quantitativer Werte zu verwenden. Sie dient als Maßein-heit. Auf Benutzerwunsch blendet das Programm die numerischen Interaktionswerteein. Tabelle 3.1 zeigt, inwiefern Farbe zur Visualisierung der Interaktionsstärke

Tabelle 3.1: Farbe zur Darstellung der Interaktionsstärke

Darstellung der Interaktionsstärke

Farbe Stärke der InteraktionGrau keineBlau geringGrün moderatGelb hochRot sehr hoch

verwendet wird. Der Verlauf der Farben, beginnend mit Blau, was einem niedrigenInteraktionswert entspricht, über Grün für durchschnittliche, Gelb für hohe, bis hinzu Rot für sehr hohe Interaktionswerte, ähnelt dem Farbverlauf der Bodentempe-ratur in Wetterkarten. Die Farbfolge entspricht dem natürlichen Empfinden, dass

36


Abbildung 3.7: Konzeptionsdiagramm – Visualisierung dateibezogener Interaktion

Rot für ein intensives (»heißes«) und Blau für ein schwach ausgeprägtes (»kaltes«)Geschehen steht.

Auf Verlangen des Benutzers werden Detailinformationen über das Segmentbeziehungsweise über die Dateiversion eingeblendet. Eine Kurzhilfe12 zeigt denInteraktionswert und weitere Einzelheiten, wie den Dateinamen, die Versionsnummer,die Benutzerkennung des Autors und das Entstehungsdatum13. Es lässt sich ablesen,zu welcher Zeit ein Artefakt welchen Interaktionswert aufwies. Die weiterentwickelteVersion des Plug-ins folgt damit der Grundversion, die ebenfalls erst auf VerlangenDetails preisgibt.

Zwei Kurvendiagramme präsentieren Durchschnittswerte. Ein Diagramm unter-halb des Bereichs, der die in farbige Segmente unterteilten, nebeneinander angeord-neten, die Dateien repräsentierenden Säulen enthält, stellt die durchschnittlichenInteraktionswerte der Dateien dar. Es lassen sich Dateien identifizieren, derenEntstehungsgeschichten von hoher Interaktion zwischen den Gruppenmitgliederngeprägt sind. Da der Interaktionswert als Indikator für das Vorliegen gemeinsamerArbeit dient, ist zu vermuten, dass jene Dateien kooperativ erstellt wurden. Dagegenentstanden Dateien mit niedrigen Durchschnittsinteraktionswerten wahrscheinlichüberwiegend in Einzelarbeit. Ein zweites, vertikal verlaufendes Kurvendiagramm

12Englisch tool tip.13Siehe Anforderung FA5.

37

3 Lösungsansatz

zeigt die jeweiligen Durchschnittsinteraktionswerte, die zu bestimmten Zeitpunktenüber alle Dateien hinweg vorlagen. Damit lassen sich Zeiträume finden, in denendie Akteure intensiv miteinander interagierten. Schließlich zieht das Programmdie vom ersten Kurvendiagramm gezeigten durchschnittlichen Interaktionswertezur Berechnung eines Gesamtdurchschnittswertes heran. Der Wert wird numerischund stets sichtbar dargestellt. Werden alle Artefakte eines Projekts in die Analyseeinbezogen, so ermöglicht der resultierende Projektinteraktionswert den Vergleichmit anderen Softwareprojekten. Die Projekte ließen sich in Bezug auf die Neigungder Projektteams zur dateibezogenen Kooperation miteinander vergleichen.

Abbildung 3.7 auf der vorherigen Seite veranschaulicht die Konzeption des Lö-sungsansatzes, Abbildung 5.11 auf Seite 62 zeigt dessen Umsetzung.

38

4 Ausgewählte LösungsdetailsDieses Kapitel beschreibt ausgewählte Details zur Lösung. Zu Beginn werden Me-triken zur Bewertung sowohl artefaktbezogener als auch projektweiter Interaktiondargestellt. Der darauf folgende Abschnitt beschäftigt sich mit der Frage, wie ir-relevante Handlungen ausgefiltert und von der Interaktionsanalyse ausgenommenwerden können. Anschließend wird die dauerhafte Speicherung der Analyseergebnis-se erläutert. Das Kapitel schließt mit einer Übersicht über das Rüstzeug, das dieBeantwortung der in Abschnitt 2.1 auf Seite 7 aufgeworfenen Fragen ermöglicht.

4.1 Metriken zur Bewertung von InteraktionDie geteilten Artefakte eines Softwareprojekts können auf zwei Ebenen untersuchtwerden (siehe Abschnitt 3.1.4 auf Seite 29). Die Interaktionsanalyse auf Projektebenedient zur Detektion projektweiter, artefaktübergreifender Kooperation, währendsich die Analyse auf Dateiebene mit artefaktbezogener Zusammenarbeit beschäf-tigt. Die Mehrzahl der im Folgenden beschriebenen Metriken zur Berechnung vonInteraktionswerten verwendet Varianten der Formel (3.1).

4.1.1 ProjektebeneTabelle 4.1 auf der nächsten Seite zeigt eine Übersicht über die Metriken derProjektebene. Sie werden über den folgenden so genannten »extension point« in dasPlug-in eingebunden1: de.feu.coeclipse.historyflow.projectMetricProvider

PM1: InteractionBerechnet den Gruppeninteraktionswert.

PM2: Interaction ContributionsBerechnet die einzelnen Interaktionsbeiträge individueller Gruppenmitglieder.

PM3: Interaction Contributions SumBerechnet den Gesamtinteraktionsbeitrag einzelner Gruppenmitglieder.

PM4: Change ActivitiesBerechnet die Anzahl der Aktionen, die zu Änderungen an den gemeinsamenArtefakten führten.

1Siehe auch http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

39

http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

4 Ausgewählte Lösungsdetails

Tabelle 4.1: Metriken auf Projektebene

Metriken auf Projektebene

Nr. NamePM1 InteractionPM2 Interaction ContributionsPM3 Interaction Contributions SumPM4 Change ActivitiesPM5 Change Activity ContributionsPM6 Change Activity Contributions Sum

PM5: Change Activity ContributionsBerechnet den Aktivitätsbeitrag individueller Gruppenmitglieder.

PM6: Change Activity Contributions SumBerechnet die Aktivität einzelner Gruppenmitglieder.

Interaction (PM1)

Metrik PM1 kalkuliert Gruppeninteraktionswerte für bestimmte Zeitspannen inner-halb des Untersuchungszeitraums. Die Zeitspannen können nicht beliebig vorgegebenwerden. Vielmehr wird das Tagwerk der Gruppenmitglieder untersucht und geprüft,ob die Aktionen, die an jenen Tagen aufgezeichnet wurden, Ausdruck von Interaktionsind. Eine feinere Granularität ist nicht angebracht, denn die gängigen Vorgehensmo-delle zur Softwareentwicklung verlangen nicht, dass die Arbeitsergebnisse häufigerals einmal täglich im Repository eines Versionsverwaltungssystems abgespeichertwerden müssen. Die Metrik prüft, ob die Aktionen, die am betreffenden Tag ausge-führt worden waren, Reaktionen auf Aktionen waren, die innerhalb des vorgegebenenGrenzwerts für die räumliche oder zeitliche Distanz liegen. Ist das Ergebnis positiv,dann lag Interaktion vor. Die Metrik betrachtet grundsätzlich sowohl die Aktionen,die am selben Tag aufraten, als auch jene Aktionen, die weiter zurückliegen. Tageohne Aktivität bleiben unberücksichtigt. Für sie werden keine Interaktionswerteermittelt. Es können sich also Lücken in der Messreihe bilden.

Der Begriff Kausalität besagt, dass eine Ursache eine Wirkung herbeiführt. Damitist eine klare zeitliche Abfolge verbunden: Die Ursache ist älter als die Wirkung. Nunstehen aufeinander bezogene Aktionen in einer Geschehen-Vor-Relation zueinander.Die auslösende Aktion muss vor der Reaktion geschehen sein. Um zu ermitteln,ob eine Aktion Ausdruck von Interaktion ist, sind die älteren Aktionen daraufhinzu prüfen, ob sie nicht weiter als die zeitliche oder räumliche Maximaldistanzentfernt sind. Fällt die Prüfung positiv aus, dann werden Aktionspaare gebildet,die in die Berechnung des Interaktionswertes einfließen. Die Metrik PM1 muss alsogrundsätzlich alle Aktionen untersuchen, die zeitlich vor der aktuell betrachtetenliegen. Sind zwei Aktionen weiter als die zeitliche Maximaldistanz voneinander

40

4.1 Metriken zur Bewertung von Interaktion

entfernt, so könnten sie wegen der möglichen räumlichen Nähe dennoch Ausdruckvon Interaktion sein. Die fehlende Möglichkeit zur Beschränkung der Menge derreaktionsauslösenden Aktionen setzt die Verarbeitungsgeschwindigkeit der Metrikerheblich herab.

Für einen im Untersuchungszeitraum [𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥] befindlichen Tag 𝑑, an demElemente zur Menge 𝐴 der Aktionen hinzugefügt wurden, berechnet die Metrikeinen Gruppeninteraktionswert 𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑). Es gilt:

𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑡𝑎𝑖≥𝑡𝑎𝑗

𝑡𝑚𝑖𝑛𝑑≤𝑡𝑎𝑖≤𝑡𝑚𝑎𝑥𝑑𝑡𝑚𝑖𝑛≤𝑡𝑎𝑗≤𝑡𝑚𝑎𝑥

𝑡𝑚𝑖𝑛≤𝑡𝑚𝑖𝑛𝑑 , 𝑡𝑚𝑎𝑥𝑑≤𝑡𝑚𝑎𝑥𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑖𝑎(𝑎𝑖,𝑎𝑗)>0


Im Unterschied zur Formel (3.1) müssen die Reaktionen 𝑎𝑖 im Zeitraum [𝑡𝑚𝑖𝑛𝑑 , 𝑡𝑚𝑎𝑥𝑑 ]des betreffenden Tages 𝑑 aufgetreten sein.

Interaction Contributions (PM2)

Metrik PM2 berechnet individuelle Interaktionsbeiträge. Grundsätzlich läge es aufder Hand, den Gruppeninteraktionswert zweimal zu bestimmen. Einmal werden dieAktionen des ausgewählten Gruppenmitgliedes berücksichtigt, beim zweiten Malnicht. Die Differenz zwischen den beiden so ermittelten Gruppeninteraktionswertenwäre dann der Interaktionsbeitrag des betrachteten Mitglieds. Die Metrik PM2verfolgt hingegen einen anderen Ansatz. Sie orientiert sich an Formel (3.1), mitder Einschränkung, dass die Reaktionen 𝑎𝑖 vom betrachteten Gruppenmitglied 𝑢stammen müssen. Analog zur Metrik PM1 wird wiederum das Tagwerk analysiertund ermittelt, wie hoch der Interaktionsbeitrag des einzelnen Gruppenmitglieds war.

𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑, 𝑢) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑡𝑎𝑖≥𝑡𝑎𝑗

𝑡𝑚𝑖𝑛𝑑≤𝑡𝑎𝑖≤𝑡𝑚𝑎𝑥𝑑𝑡𝑚𝑖𝑛≤𝑡𝑎𝑗≤𝑡𝑚𝑎𝑥

𝑡𝑚𝑖𝑛≤𝑡𝑚𝑖𝑛𝑑 , 𝑡𝑚𝑎𝑥𝑑≤𝑡𝑚𝑎𝑥𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑢𝑎𝑖=𝑢

𝑖𝑎(𝑎𝑖,𝑎𝑗)>0


Zwischen dem von Metrik PM1 berechneten Gruppeninteraktionswert und denindividuellen Beiträgen besteht der folgende Zusammenhang:

𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑) = 1𝑛·𝑛∑︁𝑖=1𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑, 𝑢𝑖)𝑖

41


Interaction Contributions Sum (PM3)

Die Metrik PM3 bildet für den Akteur 𝑢 die Summe seiner Interaktionsbeiträ-ge, die er an den im Untersuchungszeitraum [𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥] gelegenen Tagen 𝑑 zumGruppenprozess beisteuerte. Sie ist eine Variante der Metrik PM2.

𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑢) =𝑛∑︁𝑖=1𝐼𝐴(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑𝑖, 𝑢)𝑖 (4.3)

Change Activities (PM4)

Die Tagesaktivität der Gruppe wird von der Metrik PM4 bestimmt. Siesucht Tage mit Aktivität2 und zählt dann die Aktionen, welche zu Ände-rungen an den geteilten Artefakten führten. Der berechnete Wert entsprichtder Mächtigkeit beziehungsweise der Anzahl der Elemente der Menge 𝐴* ={𝑎 ∈ 𝐴 | 𝑡𝑚𝑖𝑛 ≤ 𝑡𝑚𝑖𝑛𝑑 ≤ 𝑡𝑎 ≤ 𝑡𝑑𝑚𝑎𝑥 ≤ 𝑡𝑚𝑎𝑥} jener Aktionen, die während der Dau-er [𝑡𝑚𝑖𝑛𝑑 , 𝑡𝑚𝑎𝑥𝑑 ] des jeweiligen Tages 𝑑 ausgeführt wurden. Die Tage müssen imUntersuchungszeitraum [𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥] liegen.

𝑎𝑐𝑡(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑) = |𝐴*| (4.4)

Change Activity Contributions (PM5)

Metrik PM5 schlüsselt die Aktivität der Gruppe nach individuellen Beiträgen auf.Die Aktionen der einzelnen Gruppenmitglieder werden getrennt gezählt. Auf dieseWeise bestimmt die Metrik deren Anteil an der Gruppenaktivität.

𝑎𝑐𝑡(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑, 𝑢) = |𝐴#| (4.5)

Die Menge 𝐴# enthält die Elemente aus 𝐴*, die dem betreffenden Akteur zugeordnetsind: 𝐴# = {𝑎 ∈ 𝐴* | 𝑢𝑎 = 𝑢}

Change Activity Contributions Sum (PM6)

Die von der Metrik PM5 abgeleitete Metrik PM6 ordnet die Aktionen, die imgesamten Untersuchungszeitraum verzeichnet wurden, den einzelnen Akteuren zuund bildet dann Teilsummen. Sie misst damit die Aktivität des einzelnen Gruppen-mitglieds.

𝑎𝑐𝑡(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑢) =𝑛∑︁𝑖=1𝑎𝑐𝑡(𝑡𝑚𝑖𝑛, 𝑡𝑚𝑎𝑥, 𝑑𝑖, 𝑢)𝑖 (4.6)

2Das sind Tage, an denen etwas im Repository des Versionsverwaltungssystems abgespeichertwurde.

42

4.1 Metriken zur Bewertung von Interaktion

Tabelle 4.2: Metriken auf Dateiebene

Metriken auf Dateiebene

Nr. NameDM1 Interaction Value Across RevisionsDM2 Interaction Value Between RevisionsDM3 Interaction Contributions Across RevisionsDM4 Interaction Contributions Between Revisions

4.1.2 DateiebeneDie auf der Dateiebene angesiedelten Metriken betrachten die einzelnen Versioneneines gemeinsamen Artefakts und geben darüber Auskunft, ob sie in Zusammenar-beit entstanden sind. Tabelle 4.2 führt die zur Auswahl stehenden dateibezogenenMetriken auf. Die Einbindung in das Eclipse-Zusatzprogramm erfolgt über den»extension point« de.feu.coeclipse.historyflow.fileMetricProvider.

DM1: Interaction Value Across RevisionsBerechnet für jede Version einer Datei den Gruppeninteraktionswert. AlleAktionen, die zur Entstehung einer der Vorgängerversionen führten, kommenals Auslöser von Folgeaktionen anderer Personen in Betracht. Die zugehörigenAktionspaare bilden die Grundlage für die Berechnung des Interaktionswerts.Die Metrik bestimmt einerseits, ob eine Version eines Artefakts beziehungsweiseeiner Datei möglicherweise in Kooperation entstand und andererseits, wieausgeprägt die Zusammenarbeit war.

DM2: Interaction Value Between RevisionsBerechnet für jede Version einer Datei den Gruppeninteraktionswert. Nurjene Aktionen, die zur unmittelbaren Vorgängerversion führten, werden alsmögliche Reaktionsauslöser berücksichtigt. Es wird gemessen, ob es in derZeit zwischen genau zwei aufeinander folgenden Dateiversionen zu Interaktionbeziehungsweise Kooperation kam.

DM3: Interaction Contributions Across RevisionsBerechnet den Interaktionsbeitrag eines Gruppenmitglieds, den es zur Entste-hung der Datei beisteuerte.

DM4: Interaction Contributions Between RevisionsBerechnet den Interaktionsbeitrag eines Gruppenmitglieds, den es zur Ent-stehung der Datei beisteuerte. Die Metrik berücksichtigt nur Aktionen alspotenzielle Reaktionsauslöser, die zur direkten Vorgängerversion führten. Eswerden Interaktionsbeiträge zwischen genau zwei aufeinander folgenden Datei-versionen gemessen.

43


Interaction Value Across Revisions (DM1)

Metrik DM1 berechnet Gruppeninteraktionswerte für einzelne Versionen 𝑣 einesgemeinsamen Artefakts 𝑟. Abweichend von Formel (3.1) kommen nur Aktionen 𝑎𝑖als Reaktionen in Betracht, die sich auf keine der älteren Dateiversionen beziehen.Sowohl die reaktionsauslösenden Aktionen 𝑎𝑗 als auch die späteren Folgeaktionen 𝑎𝑖müssen dasselbe Artefakt betreffen. Wiederum gilt, dass die Reaktion jünger alsder Auslöser und von einem anderen Gruppenmitglied ausgeführt worden sein muss(𝑡𝑎𝑖 ≥ 𝑡𝑎𝑗 , 𝑢𝑎𝑖 ̸= 𝑢𝑎𝑗). Beide Aktionen sind Elemente der Menge 𝐴 der Aktionen.

𝐼𝐴(𝑟, 𝑣) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑟𝑎𝑖=𝑟𝑎𝑗𝑡𝑎𝑖≥𝑡𝑎𝑗𝑣𝑎𝑖=𝑣𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑖𝑎(𝑎𝑖,𝑎𝑗)>0


Interaction Value Between Revisions (DM2)

Metrik DM2 ist eine Variante der Metrik DM1. Sie misst Interaktion, die in der Zeitzwischen zwei direkt benachbarten Versionen 𝑣 einer Datei 𝑟 stattfand. AusschließlichAktionen 𝑎𝑗, die sich auf die unmittelbare Vorgängerversion 𝑣−1 bezogen, könnenReaktionen 𝑎𝑖 verursacht haben.

𝐼𝐴(𝑟, 𝑣, 𝑣−1) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑟𝑎𝑖=𝑟𝑎𝑗𝑡𝑎𝑖≥𝑡𝑎𝑗𝑣𝑎𝑖=𝑣𝑣𝑎𝑗=𝑣−1𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑖𝑎(𝑎𝑖,𝑎𝑗)>0


Interaction Contributions Across Revisions (DM3)

Metrik DM3 ähnelt Metrik DM1. Es wird allerdings kein Gruppeninteraktionswert,sondern der Interaktionsbeitrag einzelner Gruppenmitglieder 𝑢 berechnet. Nur Re-aktionen des vorgegebenen Mitglieds fließen in die Berechnung des Interaktionswertsein.

𝐼𝐴(𝑟, 𝑣, 𝑢) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑟𝑎𝑖=𝑟𝑎𝑗𝑡𝑎𝑖≥𝑡𝑎𝑗𝑣𝑎𝑖=𝑣𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑢𝑎𝑖=𝑢



44

4.2 Filter

Für den Gruppeninteraktionswert nach Metrik DM1 und den individuellen Interak-tionsbeiträgen gilt:

𝐼𝐴(𝑟, 𝑣) = 1𝑛·𝑛∑︁𝑖=1𝐼𝐴(𝑟, 𝑣, 𝑢𝑖)𝑖

Interaction Contributions Between Revisions (DM4)

Metrik DM4 ist mit Metrik DM2 verwandt. Statt Gruppeninteraktionswerte, werdendie einzelnen Interaktionsbeiträge der Gruppenmitglieder ermittelt. Die Beiträgebeziehen sich auf das Interaktionsgeschehen, das in der Zeitspanne zwischen jeweilszwei aufeinander folgenden Dateiversionen stattfand.

𝐼𝐴(𝑟, 𝑣, 𝑣−1, 𝑢) = 1𝑚·𝑚∑︁𝑘=1𝑎𝑖,𝑎𝑗∈𝐴𝑟𝑎𝑖=𝑟𝑎𝑗𝑡𝑎𝑖≥𝑡𝑎𝑗𝑣𝑎𝑖=𝑣𝑣𝑎𝑗=𝑣−1𝑢𝑎𝑖 ̸=𝑢𝑎𝑗𝑢𝑎𝑖=𝑢


𝑖𝑎(𝑎𝑖, 𝑎𝑗)𝑘 (4.10)

Der von Metrik DM2 berechnete Gruppeninteraktionswert und die individuellenInteraktionsbeiträge stehen in folgender Beziehung zueinander:

𝐼𝐴(𝑟, 𝑣, 𝑣−1) = 1𝑛·𝑛∑︁𝑖=1𝐼𝐴(𝑟, 𝑣, 𝑣−1, 𝑢𝑖)𝑖

4.2 FilterMitunter besteht nicht nur Interesse an der Gruppe als Ganzes, sondern an einzelneGruppenmitglieder. Zur Isolierung und Untersuchung einzelner Akteure sind ausden vorhandenen Informationen die uninteressanten auszufiltern3.

4.2.1 Analyse individueller BeiträgeSoll ein einzelnes Mitglied einer Gruppe betrachtet werden, dann sind die ande-ren auszublenden. Es stellt sich die Frage, welche Aktionen der auszublendendenAkteure ausgefiltert werden sollen. Werden die betreffenden Gruppenmitgliedergewissermaßen als nicht existent behandelt, so wären deren Aktionen vorüberge-hend vollständig zu entfernen. Das hätte allerdings den Nebeneffekt zur Folge, dasssich der Interaktionsbeitrag des im Fokus stehenden Mitglieds änderte, falls esursprünglich auf die nun weggefallenen Aktionen reagiert hat. Es kämen erheblichweniger Aktionspaare zustande, die zur Berechnung von Interaktionswerten gemäß

3Siehe Anforderung FA4.

45


der Formel (3.1) herangezogen werden könnten. Aktionspaare, die eine der nunausgesonderten, reaktionsauslösenden Aktionen enthalten, würden zerfallen undkönnten nicht mehr in die Bestimmung eines Interaktionswertes einfließen. Würdenalle Aktionen der ausgeblendeten Mitglieder ausgefiltert werden, dann fielen auchdie Reaktionen des betrachteten Gruppenmitglieds auf jene Aktionen weg, denn aufausgesonderte Aktionen kann sich ein Akteur schließlich nicht mehr beziehen. Daslückenlose Ausfiltern der Aktionen der ausgeblendeten Mitglieder führte also nichtnur zum Wegfall ihrer eigenen Beiträge, sondern tangierte auch den Beitrag der zuuntersuchenden Person, die auf die betreffenden Aktionen reagiert hat.

Ein Beispiel soll das Problem veranschaulichen: Angenommen, eine Gruppesetzt sich aus den Akteuren max, erika und klaus zusammen. Alle drei arbeiteneng zusammen. Der Gruppeninteraktionswert ist hoch. Nun soll das Mitglied maxgenauer untersucht und die anderen beiden vorübergehend ausgeblendet werden.Das vollständige Ausfiltern der Aktionen von erika und klaus führte dazu, dass esnichts gäbe, worauf max hätte reagieren können. Sein Interaktionsbeitrag wäre null.Er erschiene plötzlich unkooperativ. Das gäbe die Situation jedoch nicht korrektwieder, denn er hat mit den anderen beiden Gruppenmitgliedern häufig interagiert.Tatsächlich müsste sein Interaktionsbeitrag hoch sein. Das vollständige Ausfilternvon Aktionen hätte das Ergebnis also verfälscht.

Zur Vermeidung dieses unerwünschten Nebeneffekts, berücksichtigt die imple-mentierte Filterfunktion die Position einer Aktion in der Parameterliste der Inter-aktionsfunktion 𝑖𝑎(𝑎𝑖, 𝑎𝑗) (siehe Abschnitt 3.1.3 auf Seite 26). Befindet sie sich ander Stelle 𝑎𝑖, ist sie also eine potenzielle Reaktion auf die Aktion 𝑎𝑗 eines anderenAkteurs, dann wird die Aktion ausgefiltert, kein Aktionspaar (𝑎𝑖, 𝑎𝑗) gebildet undkein Interaktionswert berechnet. Nimmt die Aktion hingegen die Position 𝑎𝑗 ein,ist sie ein möglicher Auslöser einer Reaktion, dann wird sie berücksichtigt und einInteraktionswert berechnet. Die Filterfunktion sondert also ausschließlich potenzielleReaktionen aus. Dagegen bleiben mögliche handlungsauslösende Aktionen erhalten.Nachteil dieses Ansatzes ist, dass keine fest umrissenen Teilgruppen untersuchtwerden können. Es lässt sich nicht feststellen, ob genau zwei Akteure miteinanderinteragieren, der eine also ausschließlich auf die Aktionen des anderen reagiert.Dazu müsste die Menge der reaktionsauslösenden Aktionen zu begrenzen sein. AlleAktionen der Akteure, die nicht zur Teilgruppe gehören, müssten ausgeblendetwerden können und nicht bloß diejenigen, die als Reaktion in Betracht kommen.

4.3 PersistierungDie Entstehungsgeschichte eines Artefakts, die den Zeitraum seiner Geburt bis zumgewählten Datum umfasst, ändert sich nicht mehr. Deshalb ist es unnötig, sie aufGrundlage des von einer Versionsverwaltung vorgehaltenen Artefaktquellcodes stetsaufs Neue zu erzeugen. Es ist effizienter, sie in einem persistenten Speichermediumabzuspeichern und beim Programmneustart einzulesen.

46

4.3 Persistierung

Einmal berechnete Interaktionswerte sollten nach dem Programmende erhaltenbleiben. Während artefakt- beziehungsweise dateibezogene Daten in einer Datenbankabgelegt werden, können Untersuchungsergebnisse über projektweite, artefaktüber-greifende Interaktion in XML-Dateien gespeichert werden.

4.3.1 Entstehungsgeschichte der ArtefakteDie Gewinnung der Entstehungsgeschichte eines Artefakts anhand seines vom Ver-sionsverwaltungssystem CVS verwalteten Quellcodes kann ein hohes Maß an Re-chenzeit und Arbeitsspeicher erfordern. Dieser Umstand bildet bei der parallelenUntersuchung mehrerer Artefakte, beispielsweise im Zuge der Analyse projektweiter,artefaktübergreifender Interaktion, einen Engpass, der sich auf das Leistungsver-mögen des Plug-ins negativ auswirkt. Kästel-Baumgartner, der Autor derursprünglichen Fassung des Eclipse-Plug-ins File History Flow, schlägt in [39, Ab-schnitt 6.2] vor, die Entstehungsgeschichte nicht bei jedem Programmstart neu zuerzeugen, sondern sie mit der vom Plug-in benutzten Datenbank zu verwalten. Ausdiesem Grund speichert das weiterentwickelte Plug-in die Entstehungsgeschichte inForm von Attributwerten von Objekten der Klasse AnnotateBlock in der Datenbankab und liest sie bei Bedarf zur Erzeugung von AnnotateBlock-Objekten ein. Dazuwurde die Datenbank um eine Tabelle erweitert, die diese Daten aufnimmt. DieStruktur dieser Tabelle ist in Listing 4.1 dargestellt. Eine Beschreibung der KlasseAnnotateBlock ist [39, Abschnitt 5.3] zu entnehmen.mysql> describe annotat ionBlockTable ;+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+| F i e ld | Type | Null | Key | Default |+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+| annotationBlockID | b i g i n t (20) | NO | PRI | NULL || databaseFi l e ID | int (11) | NO | PRI | NULL || s t a r tL i n e | int (11) | NO | | −1 || endLine | int (11) | NO | | −1 || s ta r tL ineOld | int (11) | NO | | −1 || endLineOld | int (11) | NO | | −1 || sourceBlockID | b i g i n t (20) | NO | | −1 || age | int (11) | NO | MUL | −1 || kind | int (11) | NO | MUL | −1 || r e v i s i on Index | int (11) | NO | MUL | −1 || r ev i s i onBlock ID | int (11) | NO | | −1 || whitespaceStrategyID | int (11) | NO | | −1 |+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+12 rows in set ( 0 . 01 sec )

Listing 4.1: Struktur der Datenbanktabelle annotationBlockTable

4.3.2 Artefaktübergreifende InteraktionswerteDie Werte projektweiter, artefaktübergreifender Interaktion hängen davon ab, welcheArtefakte Gegenstand der Analyse sind. Mit anderen Worten, das Ergebnis derMessung ist abhängig von der Auswahl der zu untersuchenden geteilten Artefakte.Wegen der vielen Zustände, die sich aus den verschiedenen Auswahlmöglichkeiten

47


ergeben, ist es wenig sinnvoll, die Messergebnisse in einer Datenbank zu speichern.Trotzdem sollte es einen Weg geben, Interaktionswerte nicht stets aufs Neue be-rechnen zu müssen, also sie zu speichern und bei Bedarf zu laden. Aus diesemGrund wurden Export- und Importfunktionen implementiert, welche sich auf dasDatenformat XML stützen4. Dabei wurde auf das Rahmenwerk Simple5 zur XML-Serialisierung zurückgegriffen. Ein so erzeugtes XML-Dokument enthält die Wer-te der Attribute von Objekten der Klasse metricResultSet, unter anderem diePfadnamen der untersuchten Artefakte, die Zeitstempel6 der täglichen Messzeit-punkte7, die zugehörigen Interaktionswerte8 sowie Angaben zur benutzten Metrik,zum Untersuchungszeitraum, zur Zeitzone sowie zu den räumlichen und zeitlichenMaximaldistanzen 𝑑𝑠𝑚𝑎𝑥 und 𝑑𝑡𝑚𝑎𝑥. Unterbrochene Berechnungen können zu einemspäteren Zeitpunkt fortgesetzt werden9. Dabei kennzeichnet der spezielle Interakti-onswert −1 die Stelle, an der die Wiederaufnahme erfolgen soll. Listing 4.2 zeigt einBeispiel einer XML-Datei.<?xml version=" 1 .0 " encoding="UTF−8" standalone=" yes " ?><metr i cResu l tSet c r ea ted="2008−11−22␣21 : 5 2 : 0 2 .588 ␣UTC" p r o j e c t=" moz i l l a " metricID'

=" de . f eu . c o e c l i p s e . h i s t o r y f l ow . metr ic . i n t e r a c t i o n . p ro j e c tw ide .'i n t e r a c t i onVa lue " s t rategyID=" de . f eu . c o e c l i p s e . h i s t o r y f l ow .'i gnoreAl lWhitespace " dtMax=" 1.2096E9" dsMax=" 3 " dNormalizedMax=" 100 " 'iaValueMax=" 141 " timezone="UTC">

<per i odS ta r t>1017619200000</ pe r i odS ta r t><periodEnd>1041379199999</periodEnd><metricElements l ength=" 1 " c l a s s=" de . f eu . c o e c l i p s e . h i s t o r y f l ow . metr ic .'

IMetricElement "><IMetricElement c l a s s=" de . f eu . c o e c l i p s e . h i s t o r y f l ow . metr ic . MetricElement ">

<va lue s l ength=" 5 "><in t>0</ in t><in t>91</ in t><in t>63</ in t><in t>38</ in t><in t>98</ in t>

</ va lue s></ IMetricElement>

</metr icElements><measur ingPoints l ength=" 5 ">

<long>1017705600000</ long><long>1017964800000</ long><long>1018310400000</ long><long>1028419200000</ long><long>1028505600000</ long>

</measur ingPoints><re s ou r c e s l ength=" 5 ">

<s t r i n g>browser / f i r e f o x /base / content / aboutDialog . xul</ s t r i n g><s t r i n g>browser / f i r e f o x /base / content /browser . c s s</ s t r i n g><s t r i n g>browser / f i r e f o x /base / content /browser . j s</ s t r i n g><s t r i n g>browser / f i r e f o x /base / content /browser . xul</ s t r i n g><s t r i n g>browser / f i r e f o x /base / content / openLocation . j s</ s t r i n g>

</ r e s ou r c e s></metr i cResu l tSet>

Listing 4.2: Beispiel einer XML-Datei4Siehe Anforderungen FA6 und FA7.5Siehe http://simple.sourceforge.net6In Millisekunden seit dem 01. 01. 1970 00:00:00 UTC.7Eine Messung erfolgt nur für Tage, an denen die Gruppenmitglieder ihre Artefaktänderungen,

ihr Tagwerk, im Versionsverwaltungssystem gespeichert haben.8Ein Interaktionswert gilt jeweils für den Tag der Messung.9Siehe Anforderung FA13.

48

http://simple.sourceforge.net

4.3 Persistierung

4.3.3 Artefaktbezogene InteraktionswerteJe komplexer die Entstehungsgeschichte eines gemeinsamen Artefakts ist, je mehrAktionen der Teammitglieder betrachtet werden müssen, desto aufwändiger ist dieBerechnung der Interaktionswerte für die einzelnen Versionen eines Artefakts bezie-hungsweise einer Datei. Die Entstehungsgeschichte des aktuellen Entwicklungsstandseiner Datei ist festgeschrieben und ändert sich nicht mehr. Das Hinzukommen einerneuen Version führt zu keiner Änderung vergangener Versionen. Deshalb brauchtder zu einer Dateiversion gehörende Interaktionswert prinzipiell nur einmal be-stimmt zu werden. Es ist sinnvoll, die berechneten Werte in einem nicht flüchtigenSpeichermedium abzuspeichern und sie beim Start des erweiterten Plug-ins FileHistory Flow wieder auszulesen. Dazu wurde das vom bisherigen Plug-in verwendeteDatenbankschema insofern angepasst, dass es nun eine zusätzliche Tabelle zur Auf-nahme dateibezogener Interaktionsdaten gibt. Listing 4.3 zeigt die Struktur dieserDatenbanktabelle.mysql> describe i n t e r a c t i onTab l e ;+−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+| F i e ld | Type | Null | Key | Default |+−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+| databaseFi l e ID | int (11) | NO | PRI | NULL || i n t e r a c t i on ID | int (10) unsigned | NO | PRI | NULL || r ev i s i on ID | varchar (255) | NO | | NULL || i n t e r a c t i onVa lue | int (11) | NO | | −1 || preferencesDSMaxPercent | f loat | NO | | −1 || preferencesDTMax | double | NO | | −1 || preferencesMaxNDValue | f loat | NO | | −1 || isDeep | t i n y i n t (1 ) | NO | | NULL |+−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+8 rows in set ( 0 . 01 sec )

Listing 4.3: Struktur der Datenbanktabelle interactionTable

In dieser Tabelle wird für jede Version einer Datei unter anderem der ganzzahligeInteraktionswert eingetragen, ferner die Grenzwerte 𝑑𝑡𝑚𝑎𝑥 und 𝑑𝑠𝑚𝑎𝑥, der Maximal-wert, den eine normalisierte zeitliche beziehungsweise räumliche Distanz annehmenkann, sowie die Kennung, ob der Interaktionswert von einer der in Tabelle 4.2 aufSeite 43 aufgeführten Metriken Interaction Value Across Revisions oder InteractionValue Between Revisions berechnet wurde10. Listing 4.4 zeigt, wie SQL-Anweisungenzur Abfrage von Gruppeninteraktionswerten formuliert werden können.mysql> select ∗ from r e v i s i o n where f i l ePa t h l ike ’%/safeMode . xul ’ order by '

databaseFi l e ID ;+−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+| databaseFi l e ID | f i l ePa t h | p r o j e c t |+−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+| 3241 | browser / f i r e f o x /base / content / safeMode . xul | moz i l l a |+−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+1 row in set ( 0 . 00 sec )

10Ist der Wert der Spalte isDeep gleich null, dann handelt es sich um die Metrik Interaction ValueBetween Revisions. Im Falle der Metrik Interaction Value Across Revisions ist er gleich 1.

49


mysql> select r ev i s i onID , i n t e r a c t i onVa lue from i n t e r a c t i onTab l e where '

databaseFi l e ID=3241 and i sDeep=1;+−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+| r ev i s i on ID | i n t e r a c t i onVa lue |+−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+| 1 . 2 | 74 || 1 . 3 | 0 || 1 . 4 | 46 || 1 . 5 | 29 || 1 . 6 | 29 || 1 . 7 | 62 |+−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−+6 rows in set ( 0 . 00 sec )

Listing 4.4: Beispiel einer SQL-Abfrage

Desweiteren wurde die Datenbank um eine Tabelle ergänzt, die die Ergebnisse derMetriken Interaction Contributions Across Revisions und Interaction ContributionsBetween Revisions aufnimmt. Die Struktur dieser Tabelle entspricht der im vorigenAbsatz genannten Tabelle, bis auf einen Aspekt. Es werden keine Interaktionswerteüber alle Angehörige des Projektteams hinweg festgehalten, sondern die Beiträgeder einzelnen Gruppenmitglieder zum Interaktionsprozess, aus dem die betrachteteDateiversion hervorging.

4.4 Rüstzeug zur Beantwortung der FragestellungAbschnitt 4.1 auf Seite 39 stellt zahlreiche Metriken zur Bewertung von sozialerInteraktion vor. Zusammen mit dem in Abschnitt 4.2 auf Seite 45 erwähntenFilter bilden sie das Rüstzeug zur Beantwortung der in Abschnitt 2.1 auf Seite 7aufgeworfenen Fragen.

4.4.1 Beantwortung der primären FragenUnter Zuhilfenahme der Metriken PM1, DM1 und DM2 lassen sich die in Tabelle 2.1auf Seite 9 aufgelisteten primären Fragen PF1 und PF2 nach der Existenz undStärke von Kooperation unmittelbar beantworten. Laut Abschnitt 2.1.2 auf Seite 8dient der Interaktionswert als Indikator für Kooperation. Ist das Messergebnis größernull, dann hat gemeinsame Arbeit wahrscheinlich stattgefunden. Die Intensität derZusammenarbeit ist proportional zum gemessenen Interaktionswert. Mit anderenWorten, der Interaktionswert korreliert mit der Intensität der Zusammenarbeit: Jehöher der Interaktionswert, desto stärker die Zusammenarbeit.

4.4.2 Beantwortung der sekundären FragenDie Metriken der Change-Activity-Familie sind insofern interessant, als dass siesowohl Hinweise auf den Arbeitseifer der Mitglieder eines Projektteams als auch aufdas soziale Gefüge liefern. Überaus aktive Personen dürften nicht nur besonders fleißigsein, sondern auch zur Gruppe der Kernentwickler gehören, während Mitglieder, dieweniger zum Projekt beisteuern, höchstwahrscheinlich Angehörige der Gruppe der

50

4.4 Rüstzeug zur Beantwortung der Fragestellung

peripheren Entwickler sind. Die Metriken liefern Indizien zur Klärung der sekundärenFrage SF2 nach der Bildung von Teilgruppen, die mit den Fragen SF1, SF3 undSF4 eng verwandt ist.

Die Frage SF5 lässt sich mithilfe der Metriken PM5 und PM6 klären, denn diesemessen die Aktivität der einzelnen Gruppenmitglieder.

Im Gegensatz dazu ist Frage SF6 nur indirekt zu beantworten. Zeigt ein Entwicklerniedrige Interaktionsbeiträge, welche sich mit den Metriken PM2, PM3, DM3 oderDM4 bestimmen lassen, aber eine hohe Aktivität, die mit den Metriken PM5 oderPM6 gemessen werden kann, dann ist das ein Hinweis darauf, dass er lieber alleinund unabhängig von den anderen Teamangehörigen arbeitet.

Frage SF7 lässt sich ohne weiteres nicht klären, weil der in Abschnitt 4.2 aufSeite 45 vorgestellte Filter nicht in der Lage ist, sowohl die Menge der handlungsaus-lösenden Aktionen als auch die der Reaktionen auf bestimmte Gruppenmitgliederzu beschränken.

Metrik DM3 ist geeignet, etwas über das Expertenwissen der Programmiererin Erfahrung zu bringen und damit die Suche nach Antworten auf die FragenSF8 und SF9 zu erleichtern. Es ist anzunehmen, dass die Höhe eines auf einbestimmtes Artefakt bezogenen Interaktionsbeitrags mit dem Kenntnisstand aufdem zugehörigen Wissensgebiet zusammenhängt. Je größer der Interaktionsbeitrag,desto profunder ist das Wissen auf dem dazugehörigen Gebiet. Diese Vermutunglässt sich durch die Untersuchung der Entstehungsgeschichte der Datei untermauern.Auf dieser Sicht steht die von Kästel-Baumgartner [39] entwickelte MetrikLines Owned By Author zur Verfügung. Sie zeigt, wer der maßgebliche Verfasser derDatei ist. Korrespondiert ein hoher Interaktionsbeitrag mit einem hohen Beitragauf Quellcodeebene, dann dürfte der Verfasser über eine hohe Sachkenntnis auf demzur Datei passenden Wissensgebiet verfügen.

Falls verschiedene Gruppenmitglieder ein Artefakt bearbeiten, dann müsste sichdas in einem Interaktionswert größer null widerspiegeln. Die dateibezogenen MetrikenDM1 und DM2 zeigen nämlich immer dann Interaktion an, wenn aufeinander bezo-gene Aktionen von verschiedenen Akteuren stammen und innerhalb der zeitlichenoder räumlichen Maximaldistanz liegen. Positive Interaktionswerte auf Dateiebenesind also ein Indiz für ein in Frage SF10 angesprochenes gemeinsames Quellcode-eigentum. Ein gemeinsames Codeeigentum wiederum ist ein Indikator für agileVorgehensmodelle wie Extreme Programming (siehe Frage SF11), wenn auch einschwacher.

Das erweiterte Eclipse-Plug-in bietet auf seiner Projektebenen-Sicht verschiede-ne Übersichtsfunktionen an. So lassen sich nicht nur tägliche Interaktions- oderAktivitätswerte ermitteln, sondern auch wöchentliche, monatliche oder jährliche.Rhythmen der Zusammenarbeit, auf die Frage SF12 anspielt, könnten auf diese Wei-se sichtbar gemacht werden. Es ist beispielsweise denkbar, dass die Zusammenarbeitim Winter intensiver ist als im Sommer beziehungsweise zur Urlaubszeit.

Probleme innerhalb der Gruppe könnten zu einem plötzlichen Abfall der Aktivitätoder der Interaktionswerte führen. Durch den Einsatz der Change-Activity- und derGruppeninteraktionsmetriken, die die beiden erwähnten Größen messen, lässt sichFrage SF13 leichter beantworten.

51

52

5 Fallstudie: Analyse von MozillaFirefox

Dieses Kapitel zeigt die visuelle Analyse des quelloffenen Softwareprojekts MozillaFirefox. Dabei wird die Benutzung des erweiterten Eclipse-Plug-ins File History Flowdemonstriert.

5.1 Visuelle AnalyseIm Rahmen dieser Abschlussarbeit ist das Zusatzprogramm File History Flow1 fürdie Entwicklungsumgebung Eclipse2 um Funktionen zur Analyse und Visualisierungvon sozialer Interaktion erweitert worden, mit dem Ziel, Kooperation in FLOSS-Projektteams zu erkennen und zu bewerten. In der Grundversion dient das Eclipse-Plug-in zur Darstellung der Entstehungsgeschichte einzelner Dateien [39].

Vor dem Einsatz des Programms sollten drei Maßnahmen getroffen werden.

1. Installation eines MySQL-Datenbanksystems, Anlegen einer Datenbank undEinrichtung eines Benutzers, der unter anderem berechtigt ist, innerhalb derDatenbank Tabellen anzulegen, zu modifizieren und zu löschen.

2. Spiegelung des Softwarearchivs des zu untersuchenden Projekts mit einemlokalen CVS-Server3 zur Leistungssteigerung von File History Flow4.

3. Assoziation der Typen der Projektartefakte mit Eclipse-Editoren5. Die-se Einstellungen können unter anderem in der Eclipse-KonfigurationsseiteGeneral > Editors > File Associations vorgenommen werden.

Nach der Installation des erweiterten Plug-ins und dem Start von Eclipse6, könnendie Zugangsdaten zum Datenbanksystem in die dafür vorgesehenen Felder der Plug-in-Einstellungsseite eingetragen werden. Bei der anschließenden Erzeugung eines

1Siehe http://www.historyflow.de2Siehe http://www.eclipse.org3Exemplarische Anleitungen zur Einrichtung wurden auf http://wiki.mozilla.org/How_to_

Create_a_CVS_Mirror und http://docs.moodle.org/en/How_to_set_up_a_CVS_mirrorveröffentlicht.

4Der Zugriff auf einen CVS-Server über ein Weitverkehrsnetz (Wide Area Network (WAN))reduziert die Verarbeitungsgeschwindigkeit unter Umständen auf ungefähr ein Zehntel.

5Artefakte, die keinem Eclipse-Editor zugeordnet sind, werden vom Plug-in ignoriert.6Gegebenenfalls ist einmalig das Kommando eclipse -clean auszuführen.

53

http://www.historyflow.de

http://www.eclipse.org

http://wiki.mozilla.org/How_to_Create_a_CVS_Mirror

http://wiki.mozilla.org/How_to_Create_a_CVS_Mirror

http://docs.moodle.org/en/How_to_set_up_a_CVS_mirror

5 Fallstudie: Analyse von Mozilla Firefox

neuen Eclipse-Projekts vom Typ Checkout Projects from CVS ist die Adressedes lokalen CVS-Servers anzugeben, der den Quellcode des zu untersuchendenSoftwareprojekts spiegelt7. Sind die Vorbereitungen abgeschlossen, dann lässt sichdie Eclipse-Perspektive History Flow öffnen.

Zunächst ist die Datenbank zu befüllen. Dazu sind die zu analysierenden Artefaktezu selektieren8, das von Eclipse bereitgestellte so genannte Team-Kontextmenü zuöffnen und der Eintrag Load History to Database zu wählen9. Nachdem dasPlug-in die Anweisung erfolgreich beendet hat10, kann die Analyse beginnen. Dieausgewählten Artefakte lassen sich auf zwei Ebenen untersuchen. In Abschnitt 3.1.4auf Seite 29 wird erläutert, dass sich die Analyse auf Projektebene mit projektwei-ter Interaktion über alle gemeinsamen Artefakte hinweg beschäftigt. Dazu werdenAktionen betrachtet, die aufeinander bezogen sind, aber zu Änderungen an unter-schiedlichen Artefakten führen. Bei der Analyse auf Dateiebene geht es hingegenum Interaktion innerhalb der Grenzen eines Artefakts. Hierbei werden aufeinanderbezogene Aktionen untersucht, die zur Modifikation desselben Artefakts führen.

5.1.1 ProjektebeneVor Beginn der Analyse müssen die Metriken kalibriert werden. Dazu sind Grenz-werte für die zeitliche und räumliche Distanz mit der in Abschnitt 3.1.3 auf Seite 28erläuterten Methode zu wählen. Im vorliegenden Fall beträgt die zeitliche Maxi-maldistanz 14 Tage, die räumliche Maximaldistanz weist einen Wert von 3 auf.Abschnitt 3.1.3 auf Seite 28 erklärt die Messung der räumlich-zeitlichen Distanz. Dernormalisierte Maximalwert beider Distanzkomponenten lautet 100. Deshalb kannder Interaktionswert maximal

√1002 + 1002 ≈ 141 betragen (siehe Abschnitt 3.1.3

auf Seite 26).Zuerst soll sich ein Überblick verschafft werden. Dazu ist das Team-Menü zu öffnen

und der Eintrag Show Interaction at Project Level auszuwählen. Das Plug-in präsentiert eine Sicht, die die Interaktionsgeschichte auf Projektebene visualisiert.Es besteht die Wahl zwischen verschiedenen Metriken, die über das so genannteView-Menü aktiviert werden können:

• PM1: Interaction

• PM2: Interaction Contributions

• PM3: Interaction Contributions Sum

7Das Plug-in kann lediglich Eclipse-Projekte untersuchen, die an einem CVS-Repository angebun-den sind.

8Das kann in der Sicht Navigator oder Project Explorer erfolgen. Siehe auch AnforderungFA1.

9Falls die Artefakte von der Datenbank bereits erfasst wurden, dann ist dieser mitunter zeit- undarbeitsspeicheraufwändige Schritt nicht vonnöten.

10Falls es eine Änderung im CVS-Repository gab, dann ist die Ausführung der Anweisunggegebenenfalls zu wiederholen.

54

5.1 Visuelle Analyse

• PM4: Change Activities

• PM5: Change Activity Contributions

• PM6: Change Activity Contributions Sum

In Abschnitt 4.1.1 auf Seite 39 werden die Metriken eingehender erläutert.Mithilfe der Metrik PM1 wird das Tagwerk der Teamangehörigen untersucht. Die

Metrik berechnet Interaktionswerte für jene Tage, an denen Aktivität zu beobachtenwar. Wie in Abschnitt 2.1.2 auf Seite 8 beschrieben, dient der Interaktionswert alsIndikator für Kooperation. Ist das Messergebnis größer null, dann fand vermutlichgemeinsame Arbeit statt. Die Intensität der Zusammenarbeit spiegelt sich imgemessenen Interaktionswert wider. Damit lassen sich die in Tabelle 2.1 auf Seite 9dargestellten primären Fragen PF1 und PF2 nach dem Vorliegen und der Stärkevon Kooperation unmittelbar beantworten.

Unter Zuhilfenahme der Metriken der Change-Activity-Familie lassen sich so-wohl Erkenntnisse über den Fleiß der Gruppenmitglieder als auch über die sozialeStruktur des Projektteams gewinnen. Besonders aktive Mitglieder sind in der Regelarbeitseifrig und steuern vergleichsweise viel zum Projekt bei. Sie gehören vermutlichzur Kernentwicklergruppe, während Personen, die wenig zum Projekt beitragen,eher der Gruppe der peripheren Entwickler angehören.

Das Plug-in ermöglicht es dem Benutzer, den Untersuchungszeitraum einzu-schränken11. Ein dynamischer Filter blendet auf Wunsch die Beiträge ausgewählterGruppenmitglieder aus. Damit wird der Benutzer in die Lage versetzt, sowohl be-stimmte Zeitabschnitte als auch ausgewählte Teammitglieder untersuchen zu können.Werden Änderungen in der Filter-Sicht vorgenommen, dann muss die Aktualisierungder Sichten auf Projekt- und Dateiebene vom Benutzer ausgelöst werden. Dazubietet die Filtersicht die Schaltfläche Repaint the flow view an.

Interaktion

Abbildung 5.1 auf der nächsten Seite zeigt den Verlauf der Gruppeninteraktion übereinen Zeitraum von ungefähr sechs Jahren (von April 2002 bis September 2008). DieJahreswerte sind die Summen der Interaktionswerte für die einzelnen Tage. Das vomPlug-in erzeugte und später um die Achsenbeschriftung ergänzte Säulendiagrammzeigt eine kontinuierliche Zunahme der Interaktionsintensität12. Im Jahr 2007 ist imVergleich zum Vorjahr eine geringe Steigerung zu beobachten. Das deutet auf einenasymptotischen Verlauf hin.

11Siehe Anforderung FA2.12Der Einbruch im Jahr 2008 ist dadurch zu erklären, dass für das letzte Quartal keine Messwerte

vorliegen. Beginnend mit der Arbeit an Mozilla Firefox Version 3.1 fand ein Wechsel zumVersionsverwaltungssystem Mercurial http://www.selenic.com/mercurial/ statt, welches vonFile History Flow nicht unterstützt wird. Das Mozilla-Firefox-Projekt lässt sich deshalb nur biszur Version kleiner 3.1 untersuchen.

55

http://www.selenic.com/mercurial/


01.01.02

01.01.03

01.01.04

01.01.05

01.01.06

01.01.07

01.01.08

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

16.000

18.000

Interaktionsintensitaet

Jahr

2002 2003 2004 2005 2006 2007 2008

Abbildung 5.1: Mozilla Firefox – jährliche Gesamtinteraktionswerte. Sie entsprechenden Summen der Interaktionswerte für die Jahrestage.

Im Hinblick auf die durchschnittlichen Tagesinteraktionswerte13 der Jahre 2002bis 2008 sind nur geringfügige Schwankungen zu verzeichnen. Tabelle 5.1 zeigt, dasses weder Ausreißer nach oben noch nach unten gibt. An dieser Stelle sei angemerkt,dass sich die Zusammensetzung des Mozilla Firefox-Projektteams über die Jahrehinweg verändert hat. Abschnitt 6.1 auf Seite 67 geht am Schluss auf eine daraufberuhende Nebenwirkung kurz ein. Im Mittel wäre ein Interaktionswert von 70,5zu erwarten, schließlich liegt das Maximum bei 141. Tatsächlich beträgt er fürden genannten Zeitraum lediglich 57. Dieser Befund bietet einen Anhaltspunkt fürdie These, dass die Mitglieder des Mozilla-Firefox-Projektteams die gemeinsameEntwicklungsaufgabe in Teilaufgaben zerlegen und diese eher in Einzelarbeit als inenger Kooperation lösen.

Tabelle 5.1: Mozilla Firefox – durchschnittliche Tagesin-teraktionswerte (Apr. 2002 bis Sep. 2008)

Durchschnittliche Tagesinteraktionswerte

2002

2003

2004

2005

2006

2007

2008

2002

—20

08

Interaktionswerta 63 58 54 57 55 55 54 57a Der Maximalwert beträgt 141.

Die Intensität der Interaktion kann übers Jahr gesehen variieren. Beispielsweiseverzeichnet das Plug-in für das Jahr 2005 wellenförmige Bewegungen. Sie sindin Abbildung 5.2 auf der nächsten Seite dargestellt. Die Werte sind die Summender Interaktionswerte für die Monatstage. Im Winter steigt der durchschnittliche13Das Plug-in präsentiert die Durchschnittswerte innerhalb der Sicht auf Projektebene, und zwar

unterhalb des Säulendiagramms.

56


01.01.05

01.02.05

01.03.05

01.04.05

01.05.05

01.06.05

01.07.05

01.08.05

01.09.05

01.10.05

01.11.05

01.12.05

0

200

400

600

800

1000

1200

1400

Monat

Jahr 2005

Jan. Feb. Maer. Apr. Mai Jun. Jul. Aug. Sep. Okt. Nov. Dez.


Abbildung 5.2: Mozilla Firefox – Wellenbewegung der monatlichen Interaktionswerte.Jeweils Summen der Interaktionswerte für die Monatstage.

Interaktionswert, im Frühjahr nimmt er ab, im Sommer wächst er an und im Herbstfällt er schließlich wieder. Diese Beobachtung liefert einen Hinweis auf den typischenArbeitsrhythmus des Mozilla-Firefox-Entwicklerteams.

Aktivität

In der Gesamtschau korreliert die Intensität der Interaktion beziehungsweise derZusammenarbeit mit der Entwickleraktivität. Abbildung 5.3 auf der nächsten Seitefördert die folgende Tendenz zu Tage: Je höher die Aktivität, also je höher dieAnzahl der Aktionen, desto ausgeprägter ist die Interaktion. Es besteht anscheinendkein direkter kausaler Zusammenhang, denn die Messergebnisse für das Jahr 2003zeigen, dass die Interaktion trotz abnehmender Entwickleraktivität ansteigen kann.

Vergleich zwischen Aktivität und Interaktionsbeitrag

Aktive Gruppenmitglieder sind relativ interaktionsfreudig. Abbildung 5.4 auf dernächsten Seite veranschaulicht dies. Es gibt Gruppenmitglieder, die zwar aktiv sind,aber weniger dazu neigen, mit den anderen zu interagieren, doch das Phänomen,dass Angehörige der Projektgruppe überhaupt keine Interaktionsbereitschaft zeigenund die geteilten Artefakte ausschließlich in Einzelarbeit bearbeiten, lässt sich nichterkennen.

Soziale Struktur des Projektteams

Tabelle 2.2 auf Seite 11 führt unter anderem Fragen auf, die sich um den Aspekt dersozialen Struktur einer Gruppe drehen. Einige lassen sich mithilfe des erweitertenEclipse-Plug-ins File History Flow beantworten. Abbildungen 5.5 auf Seite 59 und 5.6auf Seite 59 zeigen zwei Säulendiagramme, die, abgesehen von der Beschriftung derAchsen, vom Plug-in erzeugt wurden. Sie demonstrieren, dass das Mozilla-Firefox-Pro-jekt offenbar von wenigen Kernentwicklern getragen wird. Weniger als ein DutzendPersonen leistet den Großteil der Entwicklungsarbeit. Das ist an der Verteilung der

57


01.01.02

01.01.03

01.01.04

01.01.05

01.01.06

01.01.07

01.01.08

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

Jahr

2002 2003 2005 2006 2007 20082004

Anzahl der Aktionen

01.01.02

01.01.03

01.01.04

01.01.05

01.01.06

01.01.07

01.01.08

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

16.000

18.000


Jahr

2002 2003 2004 2005 2006 2007 2008

Abbildung 5.3: Korrelation zwischen Aktivität und Interaktion – oben: Metrik Chan-ge Activities, unten: Metrik Interaction, jährliche Gesamtwerte


brettw%gmail.com chanial%noos.fr philringnalda%gmail.com webmail%kmgerich.com annie.sullivan%gmail.com joe%retrovirus.com

jwalden%mit.edu mconnor%steelgryphon.com blakeross%telocity.com myk%mozilla.org sspitzer%mozilla.org rob_strong%exchangecode.com

rflint%ryanflint.com reed%reedloden.com gavin%gavinsharp.com dietrich%mozilla.com

Total activities

0

1.000

2.000

3.000

4.000

5.000

Me

tric

Va

lue

Gesamtanzahl der Aktionen

Entwickler


webmail%kmgerich.com annie.sullivan%gmail.com joe%retrovirus.com jwalden%mit.edu brettw%gmail.com rflint%ryanflint.com

myk%mozilla.org chanial%noos.fr philringnalda%gmail.com mconnor%steelgryphon.com rob_strong%exchangecode.com blakeross%telocity.com

sspitzer%mozilla.org dietrich%mozilla.com reed%reedloden.com gavin%gavinsharp.com

Total interaction contributions

0

5.000

10.000

15.000

Me

tric

Va

lue

Entwickler

Gesamtinteraktionsbeitrag

Abbildung 5.4: Vergleich zwischen Aktivität und Interaktion – Aktivität und Inter-aktionsbeitrag einzelner Mitglieder (2002—2008)

58


0

1.000

2.000

3.000

4.000

5.000

6.000

7.000

Entwickler


Abbildung 5.5: Mozilla Firefox – Aktivität der einzelnen Mitglieder (2002—2008)

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

16.000

18.000

Entwickler

Gesamtinteraktionsbeitrag

Abbildung 5.6: Mozilla Firefox – Interaktionsbeitrag der einzelnen Mitglieder (2002—2008)

Aktivitäts- und Interaktionsbeiträge zu erkennen. Die restlichen Personen, immerhinungefähr 140 an der Zahl, gehören zu den peripheren Entwicklern, die nur sporadischetwas zum Gruppenprozess beitragen. Dieser Befund stützt Mockus’ und Herbs-lebs Hypothese [45], der Kern des Entwicklerteams eines großen FLOSS-Projektsbestünde aus 12 bis 15 Personen. Nahezu 80 % der Funktionen der entwickeltenSoftware gehe auf diese Entwickler zurück.

Möglicherweise existieren sogar echte Untergemeinschaften innerhalb des Pro-jektteams. Bird et al. [10], Crowston et al. [15, 17, 18], Dinh-Trong [22] undJensen et al. [36] widmen sich Fragen dieser Art. Zählen Teammitglieder erstab insgesamt 500 Aktionen zur Gruppe der Mozilla-Firefox-Kernentwickler, dannergibt sich das in Abbildung 5.7 auf der nächsten Seite dargestellte Bild, das dieKernentwickleraktivität über einen Zeitraum von nahezu sechs Jahren (April 2002bis September 2008) zeigt. Bemerkenswert ist, dass ein Kernentwickler anscheinendselten länger als ein Jahr aktiv ist. Scheidet er aus dem Projekt aus, dann tritt jedochein anderer in seine Fußstapfen. Die Abbildungen 5.8 auf der nächsten Seite, 5.9auf der nächsten Seite und 5.10 auf Seite 61 zeigen diese Entwicklung. Nur wenigeGruppenmitglieder befassen sich über Jahre hinweg mit der Entwicklung von MozillaFirefox.

59


ben%bengoodger.com beng%bengoodger.com benjamin%smedbergs.us blakeross%telocity.com bsmedberg%covad.net dietrich%mozilla.com

gavin%gavinsharp.com joe%retrovirus.com jwalden%mit.edu mconnor%steelgryphon.com mozilla.mano%sent.com myk%mozilla.org

reed%reedloden.com rflint%ryanflint.com rob_strong%exchangecode.com sspitzer%mozilla.org

0

1.000

2.000

3.000

4.000

5.000

6.000

7.000

Kernentwickler


Abbildung 5.7: Mozilla Firefox – Kernentwickleraktivität von 2002 bis 2008 (nurMitglieder mit mehr als 500 Aktionen)




01.01.02

01.01.03

01.01.04

0

500

1000

1500

2000

2500

3000

3500

4000

4500

Jahr2002 2003 2004

Anzahl der Aktionen

Kernentwickler

Abbildung 5.8: Mozilla Firefox – Kernentwickleraktivität von 2002 bis 2004




01.01.05

01.01.06

01.01.07

0

500

1000

1500

2000

2500

3000

3500

4000

4500

Anzahl der Aktionen

Jahr2005 2006 2007

Kernentwickler

Abbildung 5.9: Mozilla Firefox – Kernentwickleraktivität von 2005 bis 2007

60





01.01.08

0

500

1000

1500

2000

2500

3000

3500

4000

4500

Jahr2008

Anzahl der Aktionen

Kernentwickler

Abbildung 5.10: Mozilla Firefox – Kernentwickleraktivität im Jahr 2008

5.1.2 DateiebeneAls Nächstes werden die geteilten Artefakte auf der Dateiebene untersucht. Aufdieser Ebene können jene Dateien besonders gut aufgespürt werden, die in ge-meinsamer Arbeit produziert wurden. Vorab sind wiederum geeignete Grenzwerteeinzustellen. Die zeitliche Maximaldistanz beträgt 14 Tage, der Wert der räumlichenMaximaldistanz lautet 15 % (siehe Abschnitt 3.1.3 auf Seite 28). Die normalisiertenDistanzen können Werte zwischen 0 und 100 annehmen. Aus den in Abschnitt 3.1.3auf Seite 26 nachzulesenden Ausführungen folgt, dass der Interaktionswert nichtgrößer als rund 141 sein kann. Die Auswahl und Aktivierung des Team-Menü-Eintrags Show Interaction at File Level führt zur Darstellung der Interakti-onsgeschichte auf Dateiebene (siehe Abbildung 5.11 auf der nächsten Seite). DasPlug-in bietet die folgenden dateibezogenen Metriken an:

• DM1: Interaction Value Across Revisions

• DM2: Interaction Value Between Revisions

• DM3: Interaction Contributions Across Revisions

• DM4: Interaction Contributions Between Revisions

Eine Beschreibung der Metriken ist Abschnitt 4.1.2 auf Seite 43 zu entnehmen.Durch Aktivierung der Metrik DM1 lässt sich einerseits bestimmen, ob ein Ar-

tefakt beziehungsweise eine Datei wahrscheinlich in Kooperation entstand undandererseits, wie ausgeprägt die Zusammenarbeit war. Das Plug-in bietet nebender Möglichkeit, den Untersuchungszeitraum einzuschränken, Beiträge bestimmterGruppenmitglieder auszublenden, die Auflösung der Zeitachse zu verändern und dieAnsicht zu vergrößern oder zu verkleinern, diverse Funktionen zur Sortierung der dar-

61


Abbildung 5.11: File History Flow – Interaktion auf DateiebeneLinkes Diagramm: dateiübergreifende Durchschnittswerte zu be-stimmten Zeitpunkten, unteres Diagramm: Dateidurchschnittswer-te, Zahlenwert unten links: Gesamtdateidurchschnittswert, farbigeSäulen: Dateien, angeordnet entlang einer Zeitachse, die Segmenterepräsentieren die Dateiversionen, die Segmentfarbe kodiert denInteraktionswert (Blau symbolisiert geringe, Grün moderate, Gelbhohe und Rot sehr hohe Interaktion), rechte Tabelle: Filter.

62


gestellten Dateien an14, die den Benutzer dabei unterstützen, Dateien aufzuspüren,die Interaktionsschwerpunkte15 bilden.

Die Betrachtung aller Projektartefakte über den Zeitraum von April 2002 bisSeptember 2008 unter Zuhilfenahme der Metrik DM1 zeigt, dass die Teamangehöri-gen nur sporadisch miteinander interagierten. Die Interaktion erstreckte sich vorallem auf die Projektbereiche components und themes. Einige der dort platzierenArtefakte weisen einen Interaktionswert von etwa 100 auf.

Der durchschnittliche Interaktionswert liegt bei einem Wert von 33. Er befindetsich weit unterhalb des theoretischen Durchschnittwertes von 70,5. Das deutet daraufhin, dass die einzelnen Artefakte über einen bestimmten Zeitraum hinweg exklusivvon jeweils einer Person in Einzelarbeit bearbeitet wurden. Diese Beobachtung sprichtfür eine individuelle Form der Zusammenarbeit und weniger für eine kooperative,die sich durch intensive gemeinsame Arbeit auszeichnet.

Angenommen, es soll ermittelt werden, woran die Gruppenmitglieder in der Wochevom 7. 8. bis zum 13. 8. 2006 arbeiteten. Nach Auswahl aller Projektartefakte oderdes Projektwurzelverzeichnisses16, führt die Aktivierung des Team-Menü-EintragsShow Interaction at Project Level zum Sichtwechsel auf die Projektebene.Der Untersuchungszeitraum kann dort auf das Jahr 2006 eingeschränkt werden. DerBenutzer wählt zum Beispiel die Metrik PM1 aus und lässt sich ein Säulendiagrammerzeugen, das eine wöchentliche Übersicht der Ergebnisse bietet. Er öffnet das Kon-textmenü der Säule, die die fragliche Woche repräsentiert und führt den Befehlzum Wechsel zur Sicht auf Dateiebene aus. Dort wird dem Benutzer ein streifenför-migen Diagramm präsentiert, das die Artefakte zeigt, die im fraglichen Zeitraumbearbeitet wurden. Er aktiviert beispielsweise die Metrik DM1, sucht anschließendein beliebiges Artefakt aus, selektiert eine Version, die in der betreffenden Wocheexistierte und weist das Plug-in an, die Artefakte gemäß der Messwerte, die sie injener Woche aufwiesen, absteigend zu sortieren. Abbildung 5.12 auf der nächstenSeite zeigt das Ergebnis dieser Befehlskette.

Expertenwissen

Die Metrik DM3 ist geeignet, etwas über das Expertenwissen der Teamangehöri-gen in Erfahrung zu bringen17. Es ist anzunehmen, dass die Höhe eines auf einebestimmte Datei bezogenen Interaktionsbeitrags mit dem Kenntnisstand auf demzugehörigen Wissensgebiet zusammenhängt. Je größer der Interaktionsbeitrag, destoprofunder ist das Wissen auf dem korrespondierenden Gebiet. Anhand von Ab-bildung 5.13 auf der nächsten Seite lässt sich mit etwas Mühe erkennen, dass derKernentwickler jwalden%mit.edu im Wesentlichen in den Bereichen componentsund preferences des Mozilla-Firefox-Projekts tätig war18. Diese Vermutung lässt

14Siehe Anforderungen FA3 und FA12.15Englisch hot spots.16Das kann in der Sicht Navigator oder Project Explorer geschehen.17Alternativ kann zum Beispiel die Metrik DM1 aktiviert werden. Bis auf das zu untersuchende

Gruppenmitglied wären alle anderen auszufiltern.18Das lässt sich mithilfe eingeblendeter Kurzhilfen feststellen, die die vollständigen Pfadnamen

und damit die Bereiche aufführen.

63


Abbildung 5.12: Mozilla Firefox – Interaktionsschwerpunkte 7. 8.—13. 8. 2006

Abbildung 5.13: Mozilla Firefox – Die Interaktionsschwerpunkte des Kernentwicklersjwalden%mit.edu lassen auf dessen Expertenwissen schließen.

64


sich dadurch absichern, indem die Entstehungsgeschichte der Datei untersucht wird.Dazu kann der Benutzer das zum Diagramm gehörende Kontextmenü öffnen undden Eintrag Show File History Flow wählen. Anschließend aktiviert er die aufdieser Sicht zur Verfügung stehende Metrik Lines Owned By Author (siehe [39,Abschnitt 5.9]). Es ist dann zu erkennen, wer der maßgebliche Verfasser der Da-tei ist. Korrespondiert ein hoher Interaktionsbeitrag mit einem hohen Beitrag aufQuellcodeebene, dann deutet das darauf hin, dass der Verfasser über eine hoheSachkenntnis auf dem zur Datei passenden Wissensgebiet verfügt. Das Beispieldes Kernentwicklers jwalden%mit.edu untermauert die Annahme, dass sich dieMitglieder eines FLOSS-Projektteams in der Regel spezialisieren. Nur wenige sindGeneralisten, die sich in breite Bereiche eines Projekts einbringen. Krogh et al. [40,Abschnitt 4.2.1] kommen zu ähnlichen Schlussfolgerungen.

65

66

6 SchlussbetrachtungDer letzte Teil dieser Abschlussarbeit geht auf Risiken der Fehlinterpretation, poten-zielle Fehlerquellen und auf Verbesserungsmöglichkeiten in Hinsicht auf die Messungvon Interaktion, des Arbeitsspeicherbedarfs und der Verarbeitungsgeschwindigkeitein. Das Kapitel endet mit einer Zusammenfassung der Ergebnisse.

6.1 Aussagekraft der MessergebnisseWas die Beurteilung von Kooperation betrifft, so ist sich bewusst zu machen, dassdie unter Zuhilfenahme des erweiterten Eclipse-Plug-ins File History Flow gewonnenenErgebnisse die Aussagekraft von Indizien haben. Zur Absicherung der Befunde undSchlussfolgerungen wäre ein Abgleich mit weiteren Datenquellen und Auswertungenvonnöten (vgl. [4, 49]), beispielsweise mit dem Archiv der zwischen den Entwick-lern eines Softwareprojekts ausgetauschten E-Mails. Die durch Benutzung von FileHistory Flow erzielten Ergebnisse sollten also stets in Kombination mit zusätzlichenInformationen interpretiert werden. An dieser Stelle sei auf zwei Arbeiten hinge-wiesen. Baysal et al. [7] stellen einen interessanten Ansatz zum Auffinden vonKorrelationen zwischen E-Mailarchiven und dem Quellcode eines Softwareprojektsvor. Gilbert et al. [29] ziehen ebenfalls E-Mailarchive zu Rate. Sie verknüpfenÄnderungen des Artefaktquellcodes mit der Konversation über das gemeinsameArtefakt, um Kooperation zwischen Gruppenmitgliedern aufzudecken.

Eines sei ausdrücklich betont: Der Interaktionswert ist lediglich ein Indikator fürKooperation. Allerdings markiert ein hoher Wert jene Stellen im Softwareprojekt,die es wert sind, genauer untersucht zu werden. Es mag sich daraufhin herausstellen,dass der Interaktionswert tatsächlich Kooperation im Projektteam angezeigt hat.

Es existieren zahlreiche Aspekte, die die Aussagekraft der Messergebnisse be-einflussen. Nicht alle Teammitglieder könnten berechtigt sein, schreibend auf dengemeinsamen Arbeitsbereich zuzugreifen. Es ist denkbar, dass einige Personen dieRolle eines Vermittlers innehaben. Sie nähmen fremde Beiträge in Empfang undspeicherten sie erst nach Prüfung im Versionsverwaltungssystem ab. Mit anderenWorten, der Urheber einer Artefaktänderung und derjenige, der diese Änderungim gemeinsamen Arbeitsbereich abgelegt, muss nicht ein und dieselbe Person sein.Das Plug-in geht allerdings davon aus, dass derjenige, der eine Artefaktmodifikationabspeichert, auch der Urheber ist. Zu beachten ist, dass die Benutzerkennung, diedas Plug-in zur Identifizierung der Gruppenmitglieder heranzieht, kein zuverlässigesAttribut ist. Eine Benutzerkennung könnte durchaus mehrere Akteure adressieren.Außerdem ist es denkbar, dass Gruppenmitglieder ihre Benutzerkennung im Laufe

67

6 Schlussbetrachtung

der Zeit ändern oder sogar unter mehreren auftreten. Das Eclipse-Zusatzprogrammist ferner nicht in der Lage, die Tätigkeiten aller Mitglieder eines Projektteamszu erfassen. Personen, die nicht programmieren beziehungsweise nicht an den ge-teilten Artefakten eines Softwareprojekts arbeiten, bleiben unberücksichtigt. Dazugehören beispielsweise Projektleiter. Ebenso erkennt das Plug-in das Ausscheidenvon Personen aus der Gruppe nicht. Einmal registrierte Akteure verbleiben ausder Sicht von File History Flow auf ewig im Projektteam. Es ist der makabere Falldenkbar, dass das Programm soziale Interaktion mit einer bereits verstorbenenPerson anzeigt. Diese Erwägungen sollen zeigen, dass es ein gravierendes Risiko fürFehlinterpretationen gibt.

6.2 Kalibrierung der MetrikenVor Gebrauch des erweiterten Eclipse-Plug-ins File History Flow sind die Metriken zukalibrieren (siehe Abschnitt 3.1.3 auf Seite 28). Dazu bietet die Einstellungsseite desPlug-ins entsprechende Eingabefelder an. Die Wahl der Grenzwerte für die zeitlichebeziehungsweise räumliche Maximaldistanz hat einen bedeutsamen Einfluss aufdie Güte der später gewonnenen Ergebnisse. Unpassende Werte sind eine möglichesystematische Fehlerquelle. Die Messwerte könnten entweder zu hoch oder zu niedrigsein: Sie zeigen Interaktion, obwohl die Akteure tatsächlich gar nicht miteinanderinteragierten oder sie weisen keine Interaktion aus, obwohl aufeinander bezogeneHandlungen vorlagen. Die Wahl geeigneter Grenzwerte erfordert Fingerspitzengefühl.Dabei bietet es sich an, nach der Strategie Versuch und Irrtum vorzugehen undjene Werte beizubehalten, die zu plausiblen Messungen führen. Sobald ein anderesSoftwareprojekt analysiert werden soll, ist die Kalibrierung erneut durchzuführen.Mitunter mag es sinnvoll sein, die Grenzwerte sogar im Verlauf der Analyse an-zupassen, beispielsweise dann, wenn Zeiträume, die eine auffällige Aktivität derGruppenmitglieder aufweisen, untersucht werden sollen.

Die Wahl der Grenzwerte besitzt besonderes Gewicht. Ungeeignete können dasAnalyseergebnis verfälschen. Das Finden eines passenden Maßes setzt ein hinrei-chendes Verständnis des Anwendungsbereichs voraus. Die mithilfe von File HistoryFlow gewonnenen Erkenntnisse unterliegen also einem beachtlichen menschlichenEinflussfaktor. Dieser Aspekt ist bei der Bewertung der Ergebnisse stets zu berück-sichtigen.

6.2.1 GewichtungAbschnitt 3.1.3 auf Seite 26 stellt eine Formel zur Berechnung von Interaktionswertenvor. Sie liefert Ergebniswerte, die von zwei Faktoren abhängen, einem räumlichenund einem zeitlichen. Die beiden Faktoren fließen gleichberechtigt in die Bestim-mung der Interaktionswerte ein. Der Autor hat im Zuge der Kalibrierung dieserFaktoren die folgende Erfahrung gemacht: Je höher der Grenzwert für die räumlicheMaximaldistanz ist, desto mehr überstrahlt der zugehörige Interaktionsanteil den

68

6.3 Leistungsvermögen

anderen, welcher auf zeitliche Zusammenhänge beruht. Die Wirkung des räumlichenAnteils neigt dazu, das Messergebnis zu dominieren. Für Abhilfe könnte eine un-terschiedliche Gewichtung der Faktoren sorgen. Becherer-Ecker schlägt einenentsprechenden Ansatz in [8] vor.

Eine verschiedene Gewichtung kann sich auch auf die gemeinsamen Artefakteerstrecken. Artefakte, die besonders häufig von den Gruppenmitgliedern modifiziertwurden, könnten bei der Bestimmung von Interaktionswerten bevorzugt berücksich-tigt werden.

Nicht zuletzt bestünde die Möglichkeit, einzelne Aktionen unterschiedlich zugewichten. Ruft eine Aktion viele Reaktionen hervor, dann wäre ihr Beitrag zumInteraktionswert höher zu bewerten. Führt eine Aktion zu umfangreichen Änderun-gen an einem gemeinsamen Artefakt, dann wäre sie wichtiger, als Aktionen, die nurgeringfügige Modifikationen verursachen.

Auch die Akteure könnten unterschiedlich behandelt werden. Denkbar wäre, dassden Aktionen von Kernentwicklern eine vergleichsweise hohe Relevanz für denresultierenden Interaktionswert zugewiesen wird.

6.3 LeistungsvermögenIm Hinblick auf die Speicheranforderungen und der Verarbeitungsgeschwindigkeitgibt es ein enormes Verbesserungspotenzial. Die nachfolgenden Abschnitte schilderneinige Anregungen.

6.3.1 SpeicherbedarfUrsprünglich dient das Eclipse-Plug-in File History Flow zur Visualisierung der Entste-hungsgeschichte einzelner Dateien (siehe [39]). Die Anforderungen sahen nicht vor,besondere Maßnahmen in Bezug auf den Speicherbedarf zu treffen. Beispielsweisefordern Objekte der Klasse HistoryModel, eine der zentralen Datenstrukturen desPlug-ins, für Dateien mit einer komplexen Entstehungsgeschichte besonders vielArbeitsspeicher an. Diese Eigenschaft spielt für die Benutzung der Grundversionkeine Rolle, schließlich wird nur eine Datei zur Zeit verarbeitet. Die erweiterteVersion untersucht aber unter Umständen alle Dateien eines Softwareprojekts, undzwar gleichzeitig beziehungsweise parallel. Die ursprünglich extrem hohen Arbeits-speicheranforderungen führten in der Regel zur Überschreitung der Kapazität anvirtuellem Speicher. Das Plug-in quittierte daraufhin regelmäßig seinen Dienst. Dieweiterentwickelte Version versucht, dieses Problem zu umgehen. Objekte, die viel Ar-beitsspeicher benötigen, werden erst bei Bedarf erzeugt1, nach Gebrauch umgehendzerstört und der belegte Arbeitsspeicher wieder freigegeben. Diese Vorgehensweisevermindert zwar die Verarbeitungsgeschwindigkeit, sorgt aber für eine wesentlicheVerringerung des Arbeitsspeicherbedarfs.

1Diese Methode wird im Englischen auch als lazy initialization bezeichnet.

69

6 Schlussbetrachtung

6.3.2 Algorithmen und MethodenEs hat sich gezeigt, dass einige der Algorithmen und Methoden, die von der Grund-version des Plug-ins übernommen wurden, in Hinsicht auf die Verarbeitungsge-schwindigkeit Optimierungspotenzial aufweisen. Darauf hat bereits der Autor jenerPlug-in-Version in [39, Abschnitt 6.2] hingewiesen. Im Kontext des ursprünglichenEinsatzzweckes fällt die niedrige Verarbeitungsgeschwindigkeit nicht weiter ins Ge-wicht. Ein Verbesserungsbedarf ist dort nicht zwingend gegeben. Im Zusammenhangmit dem neuen Anwendungsbereich, der Interaktionsanalyse, sind allerdings ne-gative Auswirkungen auf die Benutzbarkeit zu beobachten. Werden viele Dateienparallel untersucht, dann benötigt das Plug-in unter Umständen sehr viel Zeit fürseine Messungen. Darüber hinaus sind einige der vorgenommenen Plug-in-Erwei-terungen hinsichtlich des Zeitbedarfs verbesserungswürdig. Im Programmteil zurDarstellung dateibezogener Interaktion ist der Aufbau des vertikal verlaufendenKurvendiagramms (siehe Konzeptionsdiagramm 3.7 auf Seite 37) besonders zeit-aufwändig, und zwar vor allem dann, wenn im Rahmen einer Analyse ein langerUntersuchungszeitraum betrachtet wird.

6.3.3 DatenbankDatenbankseitig wurden einige Modifikationen vorgenommen. Durch eine Abän-derung des Datenbankschemas konnte die zu speichernde Datenmenge erheblichreduziert werden. Die Einführung von so genannten Indizes steigert die Geschwin-digkeit, mit der SQL-Abfragen verarbeitet werden. Es besteht weiteres Opti-mierungspotenzial. Beispielsweise ist es denkbar, die Tabellen blockTable undannotationBlockTable zu vereinigen.

6.3.4 DatengewinnungBei der Benutzung des Plug-ins stellte sich heraus, dass das CVS-Protokoll grund-sätzlich eine niedrige Leistungsfähigkeit aufweist. Deshalb ist es vorteilhaft, dieentfernten CVS-Repositories mithilfe eines lokalen CVS-Servers zu spiegeln unddas Plug-in mit jenem Server kommunizieren zu lassen. Für die Zukunft wären dieAnbindung an weitere Versionsverwaltungssysteme wie Subversion2, Git3 oder Mer-curial4 und die Implementierung effizienter Algorithmen zur Daten- beziehungsweiseInformationsgewinnung wünschenswert.

6.4 Zusammenfassung der AnalyseergebnisseDie Implementierung der Gruppeninteraktionsmetrik nach Schümmer et al. [61]durch das Eclipse-Plug-in File History Flow zeigt, dass es möglich ist, auf der Grund-

2Siehe http://subversion.tigris.org/3Siehe http://git-scm.com/4Siehe http://www.selenic.com/mercurial/

70

http://subversion.tigris.org/

http://git-scm.com/

http://www.selenic.com/mercurial/

6.4 Zusammenfassung der Analyseergebnisse

lage der Entstehungsgeschichte des Quellcodes eines FLOSS-Projekts Einblicke insoziale Prozesse und Strukturen innerhalb der Entwicklergruppe zu erlangen. DerQuellcode der geteilten Artefakte dient dabei quasi als Informationsträger. DasPlug-in ermöglicht es, sowohl artefaktbezogene als auch projektweite Kooperationin Projektteams zu erkennen und kooperativ erstellte Artefakte von denen zu un-terscheiden, die in Einzelarbeit entstanden. Verschiedene, von der zuvor erwähntenGruppenmetrik abgeleitete Metriken schaffen die Möglichkeit zur Bewertung, obund in welchem Grad Software-Projektartefakte kooperativ produziert wurden.

Die Mitglieder des Mozilla-Firefox-Projektteams scheinen die gemeinsame Ent-wicklungsaufgabe vorwiegend nicht kooperativ, sondern individuell zu lösen. Derdurchschnittliche Gruppeninteraktionsgrad, der als Indikator für Kooperation inTeams dient, liegt unterhalb des theoretisch möglichen. Nur wenige Projektartefaktewurden tatsächlich gemeinsam bearbeitet. Dieses Ergebnis spricht für eine Teile-und-herrsche-Strategie. Das Problem wird dabei in Teilaufgaben zerlegt, die vonspezialisierten Personen in Einzelarbeit gelöst werden. Die Ergebnisse der Tätigkei-ten werden anschließend additiv zusammengetragen. Läge vorwiegend kooperatives,gemeinsames Arbeiten vor, das sich durch hohe Interaktion auszeichnet, dann hätteder Durchschnittsinteraktionsgrad höher ausfallen müssen. Der negative Befunddeutet darauf hin, dass das Mozilla-Firefox-Projekt keine Affinität zu Formen ko-operativer Arbeit aufweist. Inwieweit sich diese Feststellung auf andere FLOSS-Projekte übertragen lässt, wäre zu prüfen.

71

72

Literaturverzeichnis1. Adams, Paul J. ; Capiluppi, Andrea ; Groot, Adriaan de: Detecting Agi-

lity of Open Source Projects Through Developer Engagement. In: Russo,Barbara (Hrsg.) ; Damiani, Ernesto (Hrsg.) ; Hissam, Scott A. (Hrsg.) ;Lundell, Björn (Hrsg.) ; Succi, Giancarlo (Hrsg.): Proceedings of the 4thInternational Conference on Open Source Systems Bd. 275. Milano, Ita-ly : Springer, September 2008 (IFIP). – ISBN 978–0–387–09683–4. http://dx.doi.org/10.1007/978-0-387-09684-1_30, Abruf: 2009.09.03, 333–341

2. Alonso, Omar ; Devanbu, Premkumar T. ; Gertz, Michael: Expertiseidentification and visualization from CVS. In: MSR ’08: Proceedings of the 2008international workshop on Mining software repositories. New York, NY, USA :ACM, 2008. – ISBN 978–1–60558–024–1. http://dx.doi.org/10.1145/1370750.1370780, Abruf: 2009.09.05, 125–128

3. Argyle, Michael: Soziale Interaktion. Kiepenheuer & Witsch, 1972. – ISBN3462008617

4. Avouris, N. ; Komis, V. ; Fiotakis, G. ; Margaritis, M. ; Voyiatzaki,E.: Logging of fingertip actions is not enough for analysis of learning activities.In: AIED ’05: Proc. Workshop Usage Analysis in learning systems. Amsterdam,The Netherlands, July 2005 http://hci.ece.upatras.gr/pubs_files/c101_Avouris_etal_AIED2005.pdf, Abruf: 2009.09.04

5. Bales, Robert: Social Interaction Systems: Theory and Measurement. Transac-tion Publishers, 2001. – ISBN 0765808722

6. Barros, Beatriz ; Verdejo, M. F.: Analysing student interaction processesin order to improve collaboration. The DEGREE approach. In: InternationalJournal of Artificial Intelligence in Education 11 (2000), 221–241. http://aied.inf.ed.ac.uk/members00/archive/vol_11/barros/paper.pdf, Abruf: 2009.09.03

7. Baysal, Olga ; Malton, Andrew J.: Correlating Social Interactions to ReleaseHistory during Software Evolution. In: MSR ’07: Proceedings of the FourthInternational Workshop on Mining Software Repositories. Washington, DC,USA : IEEE Computer Society, 2007. – ISBN 0–7695–2950–X. http://dx.doi.org/10.1109/MSR.2007.4, Abruf: 2009.09.04, 7

8. Becherer-Ecker, Dieter: Evaluation von Kooperation in Gruppenarbeitssyste-men, FernUniversität Hagen, Diplomarbeit, 2003. http://www.pi6.fernuni-hagen.de/Diplom/DiplomLogVisualisierung.html, Abruf: 2009.09.04

73

http://dx.doi.org/10.1007/978-0-387-09684-1_30

http://dx.doi.org/10.1007/978-0-387-09684-1_30

http://dx.doi.org/10.1145/1370750.1370780

http://dx.doi.org/10.1145/1370750.1370780

http://hci.ece.upatras.gr/pubs_files/c101_Avouris_etal_AIED2005.pdf

http://hci.ece.upatras.gr/pubs_files/c101_Avouris_etal_AIED2005.pdf

http://aied.inf.ed.ac.uk/members00/archive/vol_11/barros/paper.pdf

http://aied.inf.ed.ac.uk/members00/archive/vol_11/barros/paper.pdf

http://dx.doi.org/10.1109/MSR.2007.4


http://www.pi6.fernuni-hagen.de/Diplom/DiplomLogVisualisierung.html

http://www.pi6.fernuni-hagen.de/Diplom/DiplomLogVisualisierung.html

Literaturverzeichnis

9. Beck, Kent ; Andres, Cynthia: Extreme Programming Explained: EmbraceChange. 2. Addison-Wesley, 2004. – ISBN 0321278658

10. Bird, Christian ; Pattison, David ; D’Souza, Raissa ; Filkov, Vladimir ;Devanbu, Premkumar: Chapels in the Bazaar? Latent Social Structure in OSS.In: 16th International Symposium on the Foundations of Software Engineering(FSE 16), 2008 http://wwwcsif.cs.ucdavis.edu/~bird/papers/bird2008cbl.pdf,Abruf: 2009.09.04

11. Bratitsis, Tharrence ; Dimitracopoulou, Angelique: Data Recording andUsage Interaction Analysis in Asynchronous Discussions: The D.I.A.S. System.In: Proceedings of the 12th International Conference on Artificial Intelligencein Education (AIED 2005), workshop on Usage analysis in learning systems.Amsterdam, The Netherlands, July 2005 http://hcs.science.uva.nl/AIED2005/W1proc.pdf#page=22, Abruf: 2009.09.04

12. Bürger, Martin: Unterstützung von Awareness bei der Gruppenarbeit mitgemeinsamen Arbeitsbereichen. Herbert Utz Verlag, 1999. – ISBN 3896754815

13. Chidambaram, Laku ; Tung, Lai L.: Is Out of Sight, Out of Mind? An Empi-rical Study of Social Loafing in Technology-Supported Groups. In: InformationSystems Research 16 (2005), June, Nr. 2, S. 149–168

14. Cockburn, Alistair: Agile Software Development. Addison-Wesley Professional,2001 http://portal.acm.org/citation.cfm?id=502980. – ISBN 0201699699

15. Crowston, K. ; Howison, J. ; Crowston, K. ; Howison, J.: Hierarchy andCentralization in Free and Open Source Software Team Communications. In:Knowledge, Technology, and Policy 18 (2006), Nr. 4, 65–85. http://floss.syr.edu/publications/ktp2005.pdf, Abruf: 2009.09.03

16. Crowston, Kevin ; Annabi, Hala ; Howison, James ; Masango, Chengetai:Effective work practices for software engineering: free/libre open source softwaredevelopment. In: WISER ’04: Proceedings of the 2004 ACM workshop onInterdisciplinary software engineering research. New York, NY, USA : ACM,2004. – ISBN 1–58113–988–8. http://dx.doi.org/10.1145/1029997.1030003,Abruf: 2009.09.05, 18–26

17. Crowston, Kevin ; Howison, James: The social structure of free and opensource software development. In: First Monday 10 (2005), Nr. 2. http://floss.syr.edu/publications/first-monday-sna/, Abruf: 2009.09.03

18. Crowston, Kevin ; Wei, Kangning ; Li, Qing ; Howison, James: Core andPeriphery in Free/Libre and Open Source Software Team Communications. In:HICSS ’06: Proceedings of the 39th Annual Hawaii International Conference onSystem Sciences. Washington, DC, USA : IEEE Computer Society, 2006. – ISBN

74

http://wwwcsif.cs.ucdavis.edu/~bird/papers/bird2008cbl.pdf

http://hcs.science.uva.nl/AIED2005/W1proc.pdf#page=22

http://hcs.science.uva.nl/AIED2005/W1proc.pdf#page=22

http://portal.acm.org/citation.cfm?id=502980

http://floss.syr.edu/publications/ktp2005.pdf

http://floss.syr.edu/publications/ktp2005.pdf

http://dx.doi.org/10.1145/1029997.1030003

http://floss.syr.edu/publications/first-monday-sna/

http://floss.syr.edu/publications/first-monday-sna/


0–7695–2507–5. http://dx.doi.org/10.1109/HICSS.2006.101, Abruf: 2009.09.05,118.1

19. Despré, Christophe: Modélisation et Conception d’un Environnement de SuiviPédagogique Synchrone d’Activités d’Apprentissage à Distance, Université duMaine, France, Diss., 2001. http://www-ic2.univ-lemans.fr/~despres/these_christophe_despres_2001.pdf, Abruf: 2004.05.07

20. DiBona, Chris (Hrsg.) ; Ockman, Sam (Hrsg.) ; Stone, Mark (Hrsg.): OpenSources. London : O’Reilly & Associates, Inc., 1999 http://www.oreilly.com/catalog/opensources/book/toc.html

21. Dimitracopoulou, Angelique ; Kollias, Vassilis ; Harrer, Andre-as ; Martínez, Alejandra ; Petrou, Argyro ; Dimitriadis, Yan-nis ; Antonio, Jose ; Bollen, Lars ; Wichmann, Astrid: Kalei-doScope Network of Excellence (NoE), Project “Interaction Analysis(IA)”, Project Report D31-01, State of the Art on Interaction Analysis.http://www.rhodes.aegean.gr/ltee/kaleidoscope-ia/Publications/D%2031%201%20F_State%20of%20the%20Art%20IA%20JEIRP%20Kal%20NoE.pdf.Version: November 2005, Abruf: 2009.09.03

22. Dinh-Trong, Trung T.: The FreeBSD Project: A Replication Case Studyof Open Source Development. In: IEEE Trans. Softw. Eng. 31 (2005), Nr. 6,481–494. http://dx.doi.org/10.1109/TSE.2005.73, Abruf: 2009.09.05. – DOI10.1109/TSE.2005.73. – ISSN 0098–5589

23. Draheim, Dirk ; Pekacki, Lukasz: Process-Centric Analytical Processingof Version Control Data. In: IWPSE ’03: Proceedings of the 6th InternationalWorkshop on Principles of Software Evolution. Washington, DC, USA : IEEEComputer Society, 2003. – ISBN 0–7695–1903–2. http://dx.doi.org/10.1109/IWPSE.2003.1231220, Abruf: 2009.09.04, 131

24. Fesakis, George ; Petrou, Argiro ; Dimitracopoulou, Angelique: Col-laboration Activity Function: An Interaction Analysis Tool for ComputerSupported Collaborative Learning Activities. In: ICALT ’04: Proceedingsof the IEEE International Conference on Advanced Learning Technologies.Joensuu, Finland : IEEE Computer Society, 2004. – ISBN 0–7695–2181–9.http://dx.doi.org/10.1109/ICALT.2004.1357402, Abruf: 2009.09.05, 196–200

25. Forgas, Joseph P.: Soziale Interaktion und Kommunikation. Eine Einführungin die Sozialpsychologie. 4. Auflage. Weinheim, Germany : Verlagsgruppe JuliusBeltz: Psychologie Verlags Union Beltz, 1999. – ISBN 3621271457

26. Froehlich, Jon: Unifying Artifacts and Activities in a Visual Tool for Distribu-ted Software Teams. Irvine (Irvine, CA), University of California, Diplomarbeit,2004. http://www.cs.washington.edu/homes/jfroehli/publications/MS_Thesis_Augur.pdf, Abruf: 2009.09.03

75

http://dx.doi.org/10.1109/HICSS.2006.101

http://www-ic2.univ-lemans.fr/~despres/these_christophe_despres_2001.pdf

http://www-ic2.univ-lemans.fr/~despres/these_christophe_despres_2001.pdf

http://www.oreilly.com/catalog/opensources/book/toc.html

http://www.oreilly.com/catalog/opensources/book/toc.html

http://www.rhodes.aegean.gr/ltee/kaleidoscope-ia/Publications/D%2031%201%20F_State%20of%20the%20Art%20IA%20JEIRP%20Kal%20NoE.pdf

http://www.rhodes.aegean.gr/ltee/kaleidoscope-ia/Publications/D%2031%201%20F_State%20of%20the%20Art%20IA%20JEIRP%20Kal%20NoE.pdf

http://dx.doi.org/10.1109/TSE.2005.73

http://dx.doi.org/10.1109/IWPSE.2003.1231220

http://dx.doi.org/10.1109/IWPSE.2003.1231220

http://dx.doi.org/10.1109/ICALT.2004.1357402

http://www.cs.washington.edu/homes/jfroehli/publications/MS_Thesis_Augur.pdf

http://www.cs.washington.edu/homes/jfroehli/publications/MS_Thesis_Augur.pdf


27. Froehlich, Jon ; Dourish, Paul: Unifying Artifacts and Activities in a VisualTool for Distributed Software Development Teams. In: Proceedings of the 26thInternational Conference on Software Engineering, IEEE Computer Society,2004. – ISBN 0–7695–2163–0. http://portal.acm.org/citation.cfm?id=999443,Abruf: 2009.09.03, 387–396

28. Gacek, Cristina ; Arief, Budi: The Many Meanings of Open Source. In: IEEESoftw. 21 (2004), January—February, Nr. 1, 34–40. http://dx.doi.org/10.1109/MS.2004.1259206, Abruf: 2009.09.04. – DOI 10.1109/MS.2004.1259206. – ISSN0740–7459

29. Gilbert, Eric ; Karahalios, Karrie: CodeSaw: A Social Visualization ofDistributed Software Development. In: Baranauskas, Maria Cecília C. (Hrsg.); Palanque, Philippe A. (Hrsg.) ; Abascal, Julio (Hrsg.) ; Barbosa, SimoneDiniz J. (Hrsg.): Proceedings of the 11th IFIP TC 13 International Conferenceon Human-Computer Interaction (INTERACT 2007), Part II Bd. 4663. Rio deJaneiro, Brazil : Springer, September 2007 (Lecture Notes in Computer Science).– ISBN 978–3–540–74799–4. http://dx.doi.org/10.1007/978-3-540-74800-7_25,Abruf: 2009.09.03, 303–316

30. Gousios, Georgios ; Kalliamvakou, Eirini ; Spinellis, Diomidis: Measuringdeveloper contribution from software repository data. In: MSR ’08: Proceedingsof the 2008 international workshop on Mining software repositories. New York,NY, USA : ACM, 2008. – ISBN 978–1–60558–024–1. http://dx.doi.org/10.1145/1370750.1370781, Abruf: 2009.09.05, 129–132

31. Gousios, Georgios ; Karakoidas, Vassilios ; Stroggylos, Konstantinos ;Louridas, Panagiotis ; Vlachos, Vasileios ; Spinellis, Diomidis: SoftwareQuality Assessment of Open Source Software. In: Papatheodorou, Theo-dore S. (Hrsg.) ; Christodoulakis, Dimitris N. (Hrsg.) ; Karanikolas,Nikitas N. (Hrsg.): Current Trends in Informatics: 11th Panhellenic Conferenceon Informatics, PCI 2007 Bd. A. Athens : New Technologies Publications,May 2007 http://www.dmst.aueb.gr/dds/pubs/conf/2007-PCI-SQOOSS/html/GKSL07.htm, Abruf: 2009.09.03, 303–315

32. Gronau, Norbert: Kollaborative Engineering Communities / University of Ol-denburg. Version: 2001. http://www.kermit.ch/diplomarbeit/internetliteratur/KollaborativeEngineeringCommunities.pdf, Abruf: 2009.09.04. 2001 (WI 2001-01). – Arbeitsbericht

33. Gutwin, Carl A.: Workspace awareness in real-time distributed groupware.Calgary, Canada, University of Calgary, Diss., 1998

34. Häcker, Hartmut (Hrsg.) ; Stapf, Kurt-Hermann (Hrsg.): Friedrich Dorsch:Dorsch. Psychologisches Wörterbuch. 15. Auflage. Bern, Switzerland : VerlagHans Huber, 2009. – ISBN 3456846843

76


http://dx.doi.org/10.1109/MS.2004.1259206

http://dx.doi.org/10.1109/MS.2004.1259206

http://dx.doi.org/10.1007/978-3-540-74800-7_25

http://dx.doi.org/10.1145/1370750.1370781

http://dx.doi.org/10.1145/1370750.1370781

http://www.dmst.aueb.gr/dds/pubs/conf/2007-PCI-SQOOSS/html/GKSL07.htm

http://www.dmst.aueb.gr/dds/pubs/conf/2007-PCI-SQOOSS/html/GKSL07.htm

http://www.kermit.ch/diplomarbeit/internetliteratur/KollaborativeEngineeringCommunities.pdf

http://www.kermit.ch/diplomarbeit/internetliteratur/KollaborativeEngineeringCommunities.pdf


35. Hall, Tamara: Collaboration Baseline Study. World Wide Web Documents, In-telligence Community. http://collaboration.mitre.org/prail/IC_Collaboration_Baseline_Study_Final_Report/toc.htm. Version: 1999, Abruf: 2009.09.04

36. Jensen, Chris ; Scacchi, Walt: Role Migration and Advancement Processesin OSSD Projects: A Comparative Case Study. In: ICSE ’07: Proceedingsof the 29th international conference on Software Engineering. Washington,DC, USA : IEEE Computer Society, 2007. – ISBN 0–7695–2828–7. http://dx.doi.org/10.1109/ICSE.2007.74, Abruf: 2009.09.04, 364–374

37. Jermann, Patrick R.: Computer support for interaction regulation in collaborati-ve problem solving. Geneva, Switzerland, University of Geneva, Diss., 2004. https://documents.epfl.ch/users/p/pj/pjermann/www/thesis/thesis-jermann.pdf, Ab-ruf: 2009.09.03

38. Karau, S. J. ; Williams, K. D.: Social Loafing: A metaanalytic review andtheoretical integration. In: Journal of Personality and Social Psychology 65(1993), Nr. 4, S. 681–706

39. Kästel-Baumgartner, Harald: Visualisierung von Datei-Historien in Eclipse,FernUniversität in Hagen, Diplomarbeit, 2007. http://www.pi6.fernuni-hagen.de/publ/kaestelBaumgartner2007.pdf, Abruf: 2009.09.04

40. Krogh, Georg von ; Spaeth, Sebastian ; Lakhani, Karim R.: Community,Joining and Specialization in Open Source Software Innovation: A Case Study.In: Research Policy 32 (2003), Nr. 7, 1217–1241. http://opensource.mit.edu/papers/rp-vonkroghspaethlakhani.pdf, Abruf: 2009.09.04

41. Latane, Bibb ; Williams, Kipling ; Harkins, Stephen: Many hands makelight the work: The causes and consequences of social loafing. In: Journal ofPersonality and Social Psychology 37 (1979), June, Nr. 6, 822–832. http://dx.doi.org/10.1037/0022-3514.37.6.822, Abruf: 2009.09.04. – DOI 10.1037/0022–3514.37.6.822

42. Liu, Ying ; Stroulia, Eleni: Reverse Engineering the Process of Small NoviceSoftware Teams. In: WCRE ’03: Proceedings of the 10th Working Conferenceon Reverse Engineering. Washington, DC, USA : IEEE Computer Society, 2003.– ISBN 0–7695–2027–8. http://dx.doi.org/10.1109/WCRE.2003.1287241, Abruf:2009.09.03, 102

43. Liu, Ying ; Stroulia, Eleni ; Erdogmus, Hakan: Understanding the Open-Source Software Development Process: a Case Study with CVSChecker. In:OSS ’05: Proceedings of the First International Conference on Open SourceSystems, NRC 47453, 2005 http://oss2005.case.unibz.it/Papers/71.pdf, Abruf:2009.09.03, 154–161

77

http://collaboration.mitre.org/prail/IC_Collaboration_Baseline_Study_Final_Report/toc.htm

http://collaboration.mitre.org/prail/IC_Collaboration_Baseline_Study_Final_Report/toc.htm

http://dx.doi.org/10.1109/ICSE.2007.74

http://dx.doi.org/10.1109/ICSE.2007.74

https://documents.epfl.ch/users/p/pj/pjermann/www/thesis/thesis-jermann.pdf

https://documents.epfl.ch/users/p/pj/pjermann/www/thesis/thesis-jermann.pdf

http://www.pi6.fernuni-hagen.de/publ/kaestelBaumgartner2007.pdf

http://www.pi6.fernuni-hagen.de/publ/kaestelBaumgartner2007.pdf

http://opensource.mit.edu/papers/rp-vonkroghspaethlakhani.pdf

http://opensource.mit.edu/papers/rp-vonkroghspaethlakhani.pdf

http://dx.doi.org/10.1037/0022-3514.37.6.822

http://dx.doi.org/10.1037/0022-3514.37.6.822

http://dx.doi.org/10.1109/WCRE.2003.1287241

http://oss2005.case.unibz.it/Papers/71.pdf


44. Liu, Ying ; Stroulia, Eleni ; Wong, Kenny ; Germán, Daniel: Using CVSHistorical Information to Understand How Students Develop Software. In:MSR ’04: 1st International Workshop on Mining Software Repositories, 2004http://msr.uwaterloo.ca/papers/Liu.pdf, Abruf: 2009.09.03, 32–36

45. Mockus, Audris ; Herbsleb, James D.: Two case studies of open source soft-ware development: Apache and Mozilla. In: ACM Trans. Softw. Eng. Methodol.11 (2002), Nr. 3, 309–346. http://dx.doi.org/10.1145/567793.567795, Abruf:2009.09.05. – DOI 10.1145/567793.567795. – ISSN 1049–331X

46. Nakahara, Jun ; Hisamatsu, Shinichi ; Yaegashi, Kazaru ; Yamauchi,Yuhei: iTree: does the mobile phone encourage learners to be more involvedin collaborative learning? In: CSCL ’05: Proceedings of the 2005 conferenceon Computer support for collaborative learning, International Society of theLearning Sciences, 2005. – ISBN 0–8058–5782–6. http://portal.acm.org/citation.cfm?id=1149354, Abruf: 2009.09.03, 470–478

47. Ogawa, M. ; Ma, K.-L. ; Bird, C. ; Devanbu, P. ; Gourley, A.: Visualizingsocial interaction in open source software projects. In: APVIS ’07: Proceedingsof 6th International Asia-Pacific Symposium on Visualization, 2007. http://dx.doi.org/10.1109/APVIS.2007.329305, Abruf: 2009.09.04, 25–32

48. Ogawa, Michael ; Ma, Kwan-Liu: StarGate: A Unified, Interactive Visualizationof Software Projects. In: Proceedings of IEEE PacificVis 2008. Kyoto, Japan,March 2008. http://dx.doi.org/10.1109/PACIFICVIS.2008.4475476, Abruf:2009.09.03, 191–198

49. Pape, Bernd ; Janneck, Monique ; Klein, Martin: Logfile-Analysen zurEvaluation der didaktischen Einbettung von CSCL-Systemen am Beispiel derCommSy-Nutzung in offenen Seminaren. In: e-learning and education (eleed) 1(2005). http://eleed.campussource.de/archive/1/85/, Abruf: 2009.09.04

50. Paulik, Helmut ; Geppert, Reinhard ; Groner, Horst ; Wagner, Franz:Lexikon der Ausbildungspraxis. München : Verlag Moderne Industrie, 1975. –ISBN 3478116104

51. Quiring, Oliver ; Schweiger, Wolfgang: Interaktivität – ten years after.Bestandsaufnahme und Analyserahmen. In: Medien und Kommunikations-wissenschaft 54 (2006), Nr. 1, 5–24. http://www.m-und-k.info/MuK/hefte/Aufsatz_06_01.pdf, Abruf: 2009.09.04

52. Raymond, Eric S.: The Cathedral and the Bazaar. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Version: May 1997, Abruf:2009.09.04

53. Rossi, Maria A.: Decoding the “Free/Open Source(F/OSS) Software Puzzle” asurvey of theoretical and empirical contributions / Department of Economics,

78

http://msr.uwaterloo.ca/papers/Liu.pdf

http://dx.doi.org/10.1145/567793.567795



http://dx.doi.org/10.1109/APVIS.2007.329305

http://dx.doi.org/10.1109/APVIS.2007.329305

http://dx.doi.org/10.1109/PACIFICVIS.2008.4475476

http://eleed.campussource.de/archive/1/85/

http://www.m-und-k.info/MuK/hefte/Aufsatz_06_01.pdf

http://www.m-und-k.info/MuK/hefte/Aufsatz_06_01.pdf

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/


University of Siena. Version: April 2004. http://ideas.repec.org/p/usi/wpaper/424.html, Abruf: 2009.09.04. 2004 (424). – Department of Economics Universityof Siena. – 1–42 S.

54. Samoladas, Ioannis ; Gousios, Georgios ; Spinellis, Diomidis ; Stamelos,Ioannis: The SQO-OSS Quality Model: Measurement Based Open SourceSoftware Evaluation. In: Damiani, Ernesto (Hrsg.) ; Succi, Giancarlo (Hrsg.); IFIP 20th World Computer Congress, Working Group 2.3 on Open SourceSoftware (Veranst.): Open Source Development, Communities and Quality —OSS 2008: 4th International Conference on Open Source Systems. Boston :Springer, September 2008. http://dx.doi.org/10.1007/978-0-387-09684-1_19,Abruf: 2009.09.03, 237–248

55. Scacchi, Walt: Free/Open Source Software Development: Recent ResearchResults and Methods. In: Advances in Computers 69 (2007), 243–295. http://www.ics.uci.edu/~wscacchi/Papers/New/Draft_Chapter_Scacchi.pdf, Abruf:2009.09.04

56. Schulte-Zurhausen, Manfred: Organisation. 4., überarbeitete Auflage.Vahlen Verlag, 2005. – ISBN 3800632055

57. Schümmer, Till: GAMA - A Pattern Language for Computer Supported Dy-namic Collaboration. In: EuroPLoP ’03: Proceedings of the 8th European Con-ference on Pattern Languages of Programs, 2004 http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2003/2003_Schuemmer_GAMA.pdf, Abruf:2009.09.03

58. Schümmer, Till: Patterns for Building Communities in Collaborative Sys-tems. In: EuroPLoP ’04: Proceedings of the Ninth European Conferenceon Pattern Languages of Programs. Konstanz, Germany and Irsee, Germa-ny, 2004 http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2004/2004_Schuemmer_PatternsForBuildingCommunities.pdf, Abruf: 2009.09.03,379–440

59. Schümmer, Till: A Pattern Approach for End-User Centered GroupwareDevelopment, FernUniversität in Hagen, Diss., 2005

60. Schümmer, Till ; Lukosch, Stephan: Patterns for Computer-Mediated Inter-action. Wiley, 2007 (Wiley Software Patterns Series). – ISBN 0470025611

61. Schümmer, Till ; Strijbos, Jan-Willem ; Berkel, Thomas: A new di-rection for log file analysis in CSCL: experiences with a spatio-temporal me-tric. In: Proceedings of the 2005 conference on Computer support for col-laborative learning: learning 2005: the next 10 years! Taipei, Taiwan : In-ternational Society of the Learning Sciences, 2005. – ISBN 0–8058–5782–6.http://portal.acm.org/citation.cfm?id=1149293.1149368, Abruf: 2009.09.03, 567–576

79

http://ideas.repec.org/p/usi/wpaper/424.html

http://ideas.repec.org/p/usi/wpaper/424.html

http://dx.doi.org/10.1007/978-0-387-09684-1_19

http://www.ics.uci.edu/~wscacchi/Papers/New/Draft_Chapter_Scacchi.pdf

http://www.ics.uci.edu/~wscacchi/Papers/New/Draft_Chapter_Scacchi.pdf

http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2003/2003_Schuemmer_GAMA.pdf

http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2003/2003_Schuemmer_GAMA.pdf

http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2004/2004_Schuemmer_PatternsForBuildingCommunities.pdf

http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2004/2004_Schuemmer_PatternsForBuildingCommunities.pdf

http://portal.acm.org/citation.cfm?id=1149293.1149368


62. Seeberger, Mauricio ; Kuhn, Adrian ; Gîrba, Tudor ; Ducasse, Stéphane:Chronia: Visualizing How Developers Change Software Systems. In: CSMR’06: Proceedings of the Conference on Software Maintenance and Reengineering.Washington, DC, USA : IEEE Computer Society, 2006. – ISBN 0–7695–2536–9.http://www.iam.unibe.ch/~scg/Archive/Papers/Seeb06bChronia.pdf, Abruf:2009.09.03, 345–348

63. Semar, Wolfgang: Evaluation of a benchmark system for analyzing collaborativegroup performance as part of an educational online knowledge managementsystem. In: Arabnia, Hamid R. (Hrsg.) ; Hashemi, Ray R. (Hrsg.): IKE,CSREA Press, 2006. – ISBN 1–60132–003–5. http://www.inf-wiss.uni-konstanz.de/People/WS/IKE06-cc.pdf, Abruf: 2009.09.03, 217–223

64. Semar, Wolfgang: Leistungsvisualisierung im kollaborativen E-Learningmit Hilfe spezieller Kennzahlen. In: IWP - Information Wissenschaft &Praxis 1 (2008), 21–31. http://www.inf-wiss.uni-konstanz.de/People/WS/IWP-Kennzahlen-Semar.pdf, Abruf: 2009.09.04

65. Shneiderman, Ben: The Eyes Have It. A Task by Data Type Taxonomyfor Information Visualizations. In: Proceedings of IEEE Symposium on VisualLanguages. Boulder, CO, September 1996 http://hdl.handle.net/1903/466,Abruf: 2009.09.04, 336–343

66. Souza, Cleidson de ; Froehlich, Jon ; Dourish, Paul: Seeking the sour-ce: software source code as a social and technical artifact. In: GROUP ’05:Proceedings of the 2005 international ACM SIGGROUP conference on Sup-porting group work. New York, NY, USA : ACM, 2005. – ISBN 1–59593–223–2.http://dx.doi.org/10.1145/1099203.1099239, Abruf: 2009.09.05, 197–206

67. Stallman, Richard: Why “Open Source” misses the point of Free Software.World Wide Web Documents, GNU project – Free Software Foundation, Inc. http://www.gnu.org/philosophy/open-source-misses-the-point.html. Version: 2007,Abruf: 2009.09.04

68. Storey, Margaret-Anne D. ; Čubranić, Davor ; Germán, Daniel M.: Onthe use of visualization to support awareness of human activities in softwaredevelopment: a survey and a framework. In: Proceedings of the 2005 ACMsymposium on Software visualization. St. Louis, Missouri : ACM, 2005. – ISBN1–59593–073–6. http://dx.doi.org/10.1145/1056018.1056045, Abruf: 2009.09.05,193–202

69. Teufel, Stefanie ; Sauter, Christian ; Mühlherr, Thomas ; Bauknecht,Kurt: Computerunterstützung für die Gruppenarbeit. Oldenbourg Verlag, 1995.– ISBN 3486243705

70. Tufte, Edward R.: The Visual Display of Quantitative Information. 2. Cheshire,CT, USA : Graphics Press, 2001. – ISBN 0961392142

80

http://www.iam.unibe.ch/~scg/Archive/Papers/Seeb06bChronia.pdf

http://www.inf-wiss.uni-konstanz.de/People/WS/IKE06-cc.pdf

http://www.inf-wiss.uni-konstanz.de/People/WS/IKE06-cc.pdf

http://www.inf-wiss.uni-konstanz.de/People/WS/IWP-Kennzahlen-Semar.pdf

http://www.inf-wiss.uni-konstanz.de/People/WS/IWP-Kennzahlen-Semar.pdf

http://hdl.handle.net/1903/466

http://dx.doi.org/10.1145/1099203.1099239

http://www.gnu.org/philosophy/open-source-misses-the-point.html

http://www.gnu.org/philosophy/open-source-misses-the-point.html

http://dx.doi.org/10.1145/1056018.1056045


71. Voinea, Lucian ; Telea, Alex: CVSgrab: Mining the History of Large SoftwareProjects. In: Ertl, Thomas (Hrsg.) ; Joy, Ken (Hrsg.) ; Santos, Beatriz (Hrsg.); IEEE VGTC,EG (Veranst.): Eurographics / IEEE VGTC Symp. Visualization(EuroVis). Lisbon, Portugal : Eurographics, 2006 http://www.win.tue.nl/~alext/ALEX/PAPERS/EuroVis06/cvsgrab.pdf, Abruf: 2009.09.03, 187–194

72. Weißgerber, Peter ; Pohl, Mathias ; Burch, Michael: Visual Data Miningin Software Archives to Detect How Developers Work Together. In: MSR’07: Proceedings of the Fourth International Workshop on Mining SoftwareRepositories. Washington, DC, USA : IEEE Computer Society, 2007. – ISBN0–7695–2950–X. http://dx.doi.org/10.1109/MSR.2007.34, Abruf: 2009.09.05, 9

73. Wilson, Paul: Computer Supported Cooperative Work. Intellect Books, 1991. –ISBN 1871516269

74. Wong, Kenny ; Blanchet, Warren ; Liu, Ying ; Schofield, Curtis ; Strou-lia, Eleni ; Xing, Zhenchang: JRefleX: towards supporting small studentsoftware teams. In: eclipse ’03: Proceedings of the 2003 OOPSLA work-shop on eclipse technology eXchange. New York, NY, USA : ACM, 2003.http://dx.doi.org/10.1145/965660.965671, Abruf: 2009.09.05, 50–54

81

http://www.win.tue.nl/~alext/ALEX/PAPERS/EuroVis06/cvsgrab.pdf

http://www.win.tue.nl/~alext/ALEX/PAPERS/EuroVis06/cvsgrab.pdf


http://dx.doi.org/10.1145/965660.965671

82

ErklärungIch versichere, dass ich die vorliegende Bachelorarbeit selbständig und nur unterVerwendung der angegebenen Hilfsmittel angefertigt und die den benutzten Quellenwörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. DieArbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehördevorgelegen.

Achim, den 12. Oktober 2009Ort, Datum Unterschrift

83

84

DatenträgerAuf der beiliegenden DVD befindet sich das Eclipse-Plug-in in der Version 4.0.0.1a.Das zugehörige JAR-Archiv ist in das Verzeichnis plugins zu kopieren, welches imEclipse-Installationsverzeichnis zu finden ist. Das Plug-in steht nach einem Neustartvon Eclipse zur Verfügung. Gegebenenfalls ist dazu einmalig das Kommando eclipse-clean auszuführen.

Die DVD enthält auch den Programmquellcode. Darüber hinaus sind auf derDVD diese Abschlussarbeit in den Dokumentenformaten PDF und LATEX sowie diemithilfe von javadoc erzeugte API-Dokumentation des Programms zu finden.

Auf der DVD befindet sich ferner eine so genannte virtuelle Maschine. Sie stellteine vollständige Testumgebung (inkl. Eclipse, MySQL-Server und CVS-Mirror) fürdas Plug-in zur Verfügung. Mithilfe des beiliegenden Programms VMware Playerkann sie gestartet werden.

An dieser Stelle befindet sich die DVD.Die DVD ist mit den folgenden Informationen

beschriftet: Thema, Autor, Matr.-Nr. und Datum.

85

86