Xiaoxuan Ge 22.02.2006

MINAR „Erfahrung und Experimente im Software Engineering“

1

Beziehung von Erfahrungen + Experimenten (Forschungsfront):

Spannende Experimentergebnisse und das FLOW-Projekt

Xiaoxuan Ge

22.02.2006

2Beziehung von Erfahrungen und Experimenten - Forschungsfront 22.02.2006

Gliederung

Rückblick des Seminars Zusammenfassung von vorigen Vorträgen

Empirical Software Engineering Beziehung von Erfahrung und Experimente

Forschungsfront – Beispiele SE-Experimente Erfahrung aus einem eWorkshop: Inspections oder Pair

Programming Ein Replikationsexperiment: Evaluation der Lerneffektivität mittels

Simulationen

Das FLOW-Projekt „Should Computer Scientists experiment more?“ Zusammenfassung


Rückblick des Seminars

Erfahrungen - „experience“ Wissensmanagement

Formen der Wissensumwandlung,

Fünf-Phasen-Modell

Experience Base Experience Factory, Experience Engine

Erfahrungsbasierte Prozessverbesserung in Software CMM, QIP und GQM

Erfahrungserhebung in Projekten: Post-Mortem-Analyse Light-weight documentation of experiences (LID)

Erfahrungen aktiv suchen: FOCUS, GQM zum zielorientierten Messen und Experimentieren

Quelle: Folien zum Seminar von De Vries


Rückblick des Seminars

Experimente - „experiment“ SE-Themen, für die sich Experimente lohnen

alte und neue Experimente, eXtreme Programming und PP

Experimente in Medizin, Psychologie und Informatik im Stilvergleich Warum experimentieren, Experiment „Citrusduft“

Statistik für Experimente Professor Schneider „experimetiert“

Experimentaufbau und –design Experiment „roter Hintergrund“

Auswertung, Nutzung und Intepretation der Experimentergebnisse

Quelle: Folien zum Seminar von Twelker


Empirical Software Engineering

Ursprung: Griechischεμπειρισμό ς „empirical“ und „empiricism“ -pir- in engen Zusammenhang mit -per- im Lateinisch Bedeutung: testen oder versuchen

„experientia” „experience“

“experimentum “ „experiment“

Empirie - „empiricism“:Wissenschaftlich, auf methodischem Weg und durch absichtlich angestellte Beobachtungen und Experimente gewonnene Erfahrung. Hinzu kommen Befragungen vorher nach bestimmten Gesichtspunkten ausgewählter Individuen oder Gruppen, so genannter Probanden.

Quelle: Wikipedia

Quelle: Wikipedia


„An empirical study is really just a test that compares what we believe to what we see...“

„empirical study“: Fallstudien, Befragungen, Prototyping, Experimente

Leider bis jetzt nicht den selben Erfolg im SE N. Fenton: mangelnder statist. Design, kurzer Ausführungszeit V. Basili: Vergleich schwierig, da individueller Projekte P. Johnson: Praktiker lehnen Messungen ab

Betrachtungsweise für empirische Ansätze im SE Kosten- und Gewinnfaktoren bestätigen „key way“ um Entscheidungen zu treffen, Ergebnisse stärken Allgemeineren Prozess Ablaufpan benötigt


Zitat: Empirical Studies of Software Engineering: A Roadmap

Aufbau einer empirische Studie im SE


Konzeption einer empirischen Studie im SE:


Forschungskontext Hypothese

Gültigkeitsdefinition Studiendesign

DatenanalyseSchlussfolgerung

Durchführung der Studie


Problem mit Ziel der Studie Problemdefinition: mit entsprechenden

Fachvokabular Forschungsreview: historischen Kontext

und offenen Fragen


Essenz der Studie High-level low-level

Abstrakte Hypothese: „Meetings sind un-versichtbar in einem Software Inspection Process“

Konkrete Hypothese: „Teams, die Inspections mit Meetings durchführen, finden mehr Fehler als Teams, die Inspections ohne Meetings durchführen“



Plan zum Testen der Hypothesen Beschreibung zur physischen,

interlektuellen oder kulturellen Umfeld Definition der Variablen:

Unabhängige und abhängige Variablen Herausforderung beim Design der Studie:

Einflußreiche und glaubhafte Studien zu konzipieren Folgende Aspekte spielen eine große Rolle:

Genauigkeit der Interpretation Relevanz des Ergebnisses Einfluß auf die Forschung

in Abhängigkeit von: Ressorceneinschränkung kostenspielig Risikomanagement möglichst minimieren



Quantitative Analyse: Vergleichen der numerischen Daten zur Überprüfung der Null-Hypothese Hypothese-Test und Leistungsanalyse

Qualitative Analyse: Schlecht quantifizierbare Aspekte wie Interviews, Perspektive der Beteiligten

Einfluß auf Schlussfolgerung Konstruktionsgültigkeit: Modellierung der

abs. Hypothese durch unabhäng. und abhäng. Var.

Interne Gültigkeit: Änderung der unabhäng. Var. führt zu Änderung der abhäng. Var.

Externe Gültigkeit: Ergebnis kann verallge-meinert werden



Ergebnis Interpretation und Schlussfolgerung aus den Ergebnissen ziehen

Sicherstellen, dass genug Information geliefert wurden

alle Frage am Anfang beantwortet

zum Reproduzieren dieser Studie

Strategien zur „erfolgreichen“ Studie Klare Anforderung definieren aufschlußreiche Frage Reproduktion einer Studien Experimente wiederholen Mitbeteiligung von anderen speziell Studenten im SE Involvieren von anderen Perspektiven in qualitative Analyse

bei Befragung oder Interviews

Ein bestimmter Typ: Experiment


Ablauf eines Experiments

abbilden auf allgemeine empirische Studien


ForschungskontextHypothese

Gültigkeitsdefinition

Studiendesign

Datenanalyse

Schlussfolgerung

Quelle: Folien zum Seminar von Twelker


Forschungsfront – Beipiele SE-Experimente

Erfahrung aus einem eWorkshop:

Inspections and Pair Programming – Konkurrierend oder Ergänzend?

Ziel: Stärken, Schwächen: konkurrierend oder ergänzend?

Experimentbeschreibung: Basiert auf Erfahrungsaustausch Diskussion in einem Experten eWorkshop

Motivation: gleiche Ziele aber andere Ansätze:

Insp. CMM-basierte MethodenPP agile Software

Development Bessere Nutzung der beiden Methoden



eWorkshop: Online, gut organisiertes Meeting, ersetzt face-to-face Workshop Platform zum Erfahrungsaustausch: effizient und kostengünstig Benutzt eine Web-basierte Chatprogramm

1. Auswahl eines Themas2. Teilnehmer einladen3. Pre-meeting Info-Sheet an Teilnehmer verteilen4. Organisatoren analysieren Pre-meeting Info-Sheet5. Zusammengestellte Themen an Teilnehmer verteilen6. Pre-meeting-Training: Ausprobieren der Tools7. Control-room initialisieren mit verschiedenen Rollen8. eWorkshop ausführen9. Post-meeting Analyse und Synthese

Vorbereitungs-phase



Support Team mit Rollen: Leiter, Moderator, Schreiber, Analyitiker und Technical Support

abgestimmt und Zwischenergebnisse präsentiert

Quelle: V. Basili et al. Building an Experience Base for Software Engineering



Ergebnis Interpretation des Experten eWorkshop:

Themenasp. Ergebnis der Diskussion (Experience Base)

Auswirkung auf Qualität

Gleiches Ziel: Qualität in SD erhöhen Reduzieren von Fehlern, die zur nächsten Phase durchschlüpfen

Insp.: hohe Qualität (low rates of defect slippage) hohe Kosten

PP: braucht mehr Beweis weniger Kosten

Perspektive des dritten Beteili

gten

(Third party perspective)

Insp.: Mit „Third party perspective“

zusätzlichen Feedback

Ermöglicht Fokus auf zusätzlichen Aspekte mit großem Einfluß

PP: Fehlen von „Third party perspective“

Kollektiver Codebesitz und Rotationsprinzip im Entwicklungsteam „könnte“ evtl. diesen Mangel umgehen

Wirkungs-zyklus

(feedback cyc.)

Je kürzer, umso besser

Insp.: langer Feedbak Zyklus Erreichen stabilen Zustands

PP: kurzer Feedback Zyklus Fehler sofort von Partner gefunden

Quelle: F. Shull et al. Inspections and Pair Programming – competing or complementary?



Ein Replikationsexperiment: Evaluation der Lerneffektivität mittels Simulationen in der Lehre der Software Projektmanagement

Motivation: Hohe Bedarf an trainierten erfahrenen Software Project Manager Studenten nur Fachwissen, aber keine Erfahrungen in der

Software Project Planning Ziel:

Informatikstudenten effizient SPP belehren Erfahrung gewinnen Experimentbeschreibung:

An Universitäten mit Studenten in zwei Gruppen: COCOMO versus System Dynamic Simulation Model

Initialexperiment: Uni Kaiserslautern Replikationsexperiment: University of Oulu


COCOMO (Constructive Cost Model) zur Kosten- bzw. Aufwandsschätzung in Pers.Mon, Mannjahr Anzahl von Codezeilen und Erfahrungswerten Meistens angesehen als Industriestandard

SD Simulations Modell Ganzheitliche Analyse und

(Modell-) Simulation kompl. und dynam. Systeme

Auswirkungen von Mgmt- Entscheidungen auf die Systemstruktur und System- verhalten

Unternehmenserfolg DYNAMO, Powersim ...



Experimentaufbau:

Pre-Test und Post-Test Effektivitätsmessung: abhäng. Var.

Y.1: Eigene Interesse an SPM

Y.2: Wissen über typischen Verhaltensmuster von SDP

Y.3: Verständnis über einfache Projekt Dynamik

Y.4: Verständnis über komplexe Projekt Dynamik


GAGB

Quelle: An Externally Replicated Experiment for Evaluating the Learning Effectiveness


Hypothese zum Experiment:H0,1: Positive Lerneffektivität Steigerung der Lerneffektivität in beiden Gruppen

scorepre (Y.i; A) = scorepost (Y.i; A),scorepre (Y.i; B) = scorepost (Y.i; B) for i = 1,…, 4

H0,2: SD Simulation Modell bessser als COCOMO Lerneffektiviät in Gruppe A ist höher als in Gruppe Ba: “relative Lerneffektivität” Leistungsverbesserung zwischen pre-test post-test

scorediff (Y.i; A) = scorediff (Y.i; B) for i = 1,…, 4b: “absolute Lerneffektivität”: post-test abhängig von der Art des Trainings

scorepost (Y.i; A) = scorepost (Y.i; B) for i = 1,…, 4



Experimentdurchführung:Block 1- Einleitung: Aufgabe PM und typ. Probleme DiskussionenBlock 2 - Rollenspiel: Illustration Projekt, interaktiv, Rolle eines PM SD Modell web-bas. Role-PlayBlock 3 - Planungsphase: Modelle kennenlernen, Konzept erstellen Präsentation wichtigen AspekteBlock 4 - Applikation: Modell konkret aufbauen Beispielprojekt ausführen




Datenanalyse:




Experimentergebnisse: Wiederlegung der Hypothesen H0,1, H0,2a und H0,2b

Steigung der Lerneffektivität von pre-test und post-test

Gruppe A (SD Simulation Modell) besseren Verständnis über die PD-Verhalten (Lerneffektivität) als Gruppe B (COCOMO)

Befragung: web-basierte Role-play Tool gut angekommen

durch Ergebnis bestätigt

Gewinn aus dem Experiment: Experiment reproduziert

Bestätigen dasgleiche Ergebnis Probanden: Studenten Bestätigt Konzept der emp. Stud.


Andere Projekte?


Das FLOW-Projekt

Projekt seit 2004 am SE-Lehrstuhl an der Uni Hannover Motivation:

Ständige Anpassung an die Anforderungen von Kunden Ziel:

Qualitätssicherung von Software FLOW: Informations- und Erfahrungsflüsse Analyse des FLOWs

Software Engineering nach Maß (Tailoring)

Konzept der Flüssen in Projekten Projektinformationen Methoden- und SE-Wissen Erfahrungen Quelle: K. Schneider,

Folien der Antrittsvorlesung


Das FLOW-Projekt

Ständiger Fluss von FLOWs in einem Projekt

Analyse der FLOWs: durch Experimenten

Quelle: K. Schneider, Folien der Antrittsvorlesung


Should Computer Scientist experiment more?

Jahr Zitierungsrate in %

EMSE IEEE (TSE)

IST

1996 70 94 53

1997 63 94 58

1998 77 88 44

1999 58 57 44

2000 20 43 21

2001 14 21 14

durchschn. ZR 50 66 38

Fakten, die dafür sprechen? Durchschnittliche Zitierungsrate Maß für Stellenwert einer

Artikel in der Wissenschaft

Quelle: Have twenty-five years of Empirical SE made a difference?


Victor Basili

Andreas JedlitschkaMarvin Zelkowitz

Pekka Abrahamsson

Forrest Shull

Walter Tichy

„Die große Familie“:




Fraunhofer USA Inc. Center for Experimental Software Engineering in Maryland

Fraunhofer IESE Institut für Experimentelles Software Engineering

ISERN Zweig: ISERN Experiment

ISESE: Symposium on empirical SE

CeBASE: Center for empirically based SE

www.empirical.jp Empirical Approach to SE

Quelle: www.empirical.jp

http://www.empirical.jp/



Zitate von Walter Tichy:

“… As computer science leaves adolescence behind, I hope to see the experimental branch of this discipline flourish!”

Zitat: Should Computer Scientist experiment more?

“Experimentation is central to the scientific process. Only experiments test theories. Only experiments can explore critical factors and bring new phenomena to light so that theories can be formulated and corrected….”


Zusammenfassung

Empirical Software Engineering in engen Zusammenhang mit Erfahrung und Expereimenten

Empirische Studien: Studiendesign relevante und einflußreiche Ergebnisse erzielen Schlussfolgerung glaubhaft und präzise interpretiert Erfolgreich? Reproduzierbarkeit einer Studie

Beispielprojekte eWorkshop und Replikationsexperiment Das FLOW-Projekt: SE nach Maß

Fakten, die für das „Experimentieren“ im SE sprechen: Durschnittliche Zitierungsrate wichtigsten Wissenschaftler und Institutionen

Vielen Dank für Ihre Aufmerksamkeit!


Literaturen

1998 Should Computer Scientists Experiment More? Tichy2000 Empirical Studies of Software Engineering: A Roadmap2001 A Controlled Experiment to Assess the Effectiveness of Inspecti

on Meetings2001 Building an Experience Base for Software Engineering: A report

on the first CeBASE eWorkshop, Basili2002 An Externally Replicated Experiment for Evaluating the Learnin

g Effectiveness of Using Simulations in Software Project Management Education

2002 Has Twenty-five Years of Empirical Software Engineering Made a Difference?

2004 Folien der Antrittsvorlesung, Schneider2004 Empirical Software Engineering Platform and Empirical Project

Monitor www.empirical.jp2005 Inspections and Pair Programming – competing or complement

ary? Experiences from an Expert eWorkshop, Basili, Shull2005 Empirical study design in the area of High-Performance

Computing (HPC), Basili, Shull

http://www.empirical.jp/

Xiaoxuan Ge 22.02.2006

Documents

Transcript of Xiaoxuan Ge 22.02.2006