Case Studies in Computer Science (Paper, German)

Transcript

1. 1.

   Richtlinien für Fallstudien in der Software-Entwicklung Pascal Hertleif hertleif@cs.uni-bonn.de Zusammenfassung

   Fallstudien sind umfangreiche empirische Untersu- chungen, welche in dem natürlichen Umfeld des Studiengebiets durch- geführt werden. Um Fallstudien erfolgreich im Bereich der Software- Entwicklung betreiben zu können, sollen bestimmte Richtlinien und Vor- gehensweisen vorgestellt werden. Diese Arbeit richtet sich an Neulinge in diesem Bereich, die einen Überblick über die Thematik erhalten wollen. 1 Einleitung Die Fallstudie (case study) ist eine Forschungsmethode, welche auf empirische Weise mittels mehrerer qualitativer wie auch quantitativer Datenquellen einzelne Phänomene (phenomena) untersucht. Im Gegensatz zu klassischen Experimen- ten werden diese nicht in einer abgeschlossenen wissenschaftlichen Umgebung betrachtet, sondern in dem jeweiligen natürlichen Umfeld [1]. Fallstudien können verschiedenen Zwecken dienen. In [1] und [2] wird zwi- schen erforschenden (exploratory), beschreibenden (descriptive), erklärenden (ex- planatory) und verbessernden bzw. auswertenden (improving bzw. evaluatory) Fallstudien unterschieden. Fallstudien sind abzugrenzen von statistischen Erhe- bungen bzw. Umfragen, Experimenten und anwendungsbezogenen Forschungen. Diese Eigenschaften führen dazu, dass Fallstudien in richtiger Anwendung tiefere Einblicke und besseres Verständnis zu dem untersuchten Phänomen er- möglichen. Die richtige Durchführung ist jedoch von erheblicher Bedeutung, da ansonsten die Forschungsergebnisse von den Eindrücken und Annahmen der For- scher gefärbt, schlecht auf allgemeinere Thesen übertragbar oder wenig aussa- gekräftig sein können. Unter anderem aus diesem Grund sind in dem Bereich der Software-Entwicklung Fallstudien im Vergleich zu anderen wissenschaftli- chen Feldern zur Zeit noch unterrepräsentiert und werden trotz steigender An- erkennung in vielen Fällen nicht in angemessenem Umfang durchgeführt [1]. Die Quellen [1], [2] und [3] stellen allesamt Konzepte und Richtlinien zur Durchführung von Fallstudien im Bereich der Software-Entwicklung vor, welche sich in ihrem abstrakten Aufbau nicht gravierend unterscheiden. So steht zu Beginn der Forschungsarbeit das sorgfältige Planen der Fallstudie, zu welchem u.a. die Bestimmung der Forschungsziele und die Auswahl der Fallstudien ge- hört, sollten mehrere durchgeführt werden und zur Option stehen. Darauf folgt die Vorbereitungs-Phase, wo neben dem Bearbeiten von administrativen Aufga- ben auch die konkreten Forschungsfragen und die Methoden zum Sammeln und
2. 2.

   Verwalten von Daten bestimmt werden. Das Erlangen der Daten (Beweisen,

   evi- dence) selbst aus verschiedenen Quellen, von denen einige exemplarisch vorge- stellt werden, wird gefolgt von der Analyse selbiger. Über den gesamten Verlauf der Fallstudie hinweg sollte der Forschungsbericht zur Studie stets ergänzt und aktualisiert werden, sodass er den Verlauf der Fallstudie widerspiegelt und mit dem Einfügen der Analyse-Ergebnisse und deren Bezug auf die Forschungsfragen finalisiert werden kann. 2 Planen und Vorbereiten von Fallstudien Zu Beginn der Forschung soll nach [2] und [3] geprüft werden, welche Fallstudi- en angemessen sind (sollten mehrere Studien zusammen durchgeführt werden), indem neben umfangreicherer Recherche zu dem speziellen Fall auch untersucht wird, ob die zu stellenden Forschungsfragen durch eine Fallstudie beantwortet werden können. Dies trifft vor allem auf Fragen nach dem Grund und der Art und Weise, wie auch bei vergleichenden (mehreren) Fallstudien zu. Das Planen der Fallstudie selbst wird in [1] dadurch spezifiziert, dass ver- schiedene Entscheidungen getroffen werden, welche die Fallstudie definieren. So soll hier das Ziel1, das zu untersuchende Phänomen bzw. der Fall2, die Referenz- Theorie bzw. -Perspektive3, die zu stellenden Forschungsfragen4, sowie die Quel- len der Daten und Methoden zum Sammeln derselben bestimmt werden. Nach Bestimmung dieser Entscheidungen sieht [2] (vgl. Abschnitt IV) ei- ne detailliertere Ausarbeitung der grundlegenden Merkmale der Fallstudie vor, wobei besonders Wert auf die Auswertbarkeit der Forschungsfragen und die Spezialisierung der Studie gelegt wird. Dazu sollen z.B. aus den Forschungs- fragen Forschungs-Behauptungen (research propositions oder später hypotheses) erzeugt werden, welche in der Studie widerlegt oder bestätigt werden. Auch soll bestimmt werden, wie die Ergebnisse zu messen sind (z.B. Zeitgewinne oder die Einfachheit der Benutzung) und wie auf Basis dessen die qualitativen Daten zu analysieren sind. Im Anschluss daran soll bestimmt werden, welche Schauplätze oder einzelne Personen als Teilnehmer gesucht werden. Dazu sind verschiedene Auswahlkri- terien und Einschränkungen (boundaries) möglich. So werden z.B. verschiedene Abteilungen eines Unternehmens betrachtet, welche möglichst ähnlich Ergeb- nisse erzielt haben. Des weiteren sollen nur Meinungen von Personen/Gruppen untersucht werden, welche aus erster Hand Erfahrungen mit der untersuchten Technologie haben oder diese mit entwickelt haben [2,3]. 1 objective, z.B. Erforschen, beschreiben oder erklären (s.o), warum eine Technologie zu einer beschleunigten Software-Entwicklung führt. 2 case, z.B. ein Software-Projekt oder eine bestimmte Technologie 3 theory (frame of reference), z.B. die Annahme, die Technologie ermögliche eine fle- xiblere Software-Entwicklung 4 research questions, z.B. »Ändert sich der Entwicklungs-Verlauf bei Verwendung die- ser Technologie?«
3. 3.

   Werden mehrere (vergleichende) Fallstudien durchgeführt, so muss zudem bestimmt werden,

   welche Studien überhaupt durchgeführt werden und außer- dem, ob eine Pilot-Studie zur Überprüfung der bisher geplanten Maßnahmen realisiert werden soll [2]. Zur Vorbereitung auf die nächsten Phase soll in der Vorbereitungs-Phase weiterhin bestimmt werden, auf welche Weise die Daten gesammelt (verschiede- ne Datenquellen, s.u.), gespeichert, validiert und verglichen (bei vergleichenden Fallstudien) werden sollen. Außerdem sollen bestimmte Risikofaktoren einge- schränkt werden, z.B. durch Vermeiden der Auswahl von Personen zum Testen einer Technologie, welche entweder mit dieser bereits vertraut, oder dafür über- haupt nicht qualifiziert sind [2]. Eine weitere wichtige Aufgabe der Planungsphase, die jedoch während der sonstigen Planung ausgeführt werden kann und nicht von ihr abhängt, ist es, ad- ministrative Fragen zu klären. So müssen in Zusammenarbeit mit Unternehmen und anderen Institutionen neben terminlichen und personellen Vereinbarungen auch juristische Fragen und solche im Bezug auf die Vertraulichkeit der erhobe- nen Daten beantwortet werden, von welchen unter anderem die Veröffentlichung des finalen Forschungsberichts abhängt [2]. Das Studien-Protokoll (case study protocol) wird zunächst als Sammlung der bisher getroffenen Entscheidungen angelegt und in den folgenden Phasen durch weitere Konventionen und gesammelte Daten ergänzt, um den finalen For- schungsbericht (report) zu formen. Wie oben erwähnt, hat das frühe Anlegen und stetige Erweitern des Protokolls die Vorteile, dass die getroffenen Entscheidun- gen stets gesammelt zur Verfügungen stehen und dass den einzelnen Forschern einen Überblick über die zu sammelnden Daten gegeben wird. Es ist hilfreich, das Protokoll extern gegenlesen zu lassen, um Fehler und Inkonsistenzen zu vermei- den. Am Ende der Planungsphase soll das Protokoll bzw. der Fallstudien-Plan die gesamte vorgesehene Durchführung der Studie abdecken und beschreiben. Beim Abschluss der Fallstudie liegt diese als vollständiger Forschungsbericht vor, welcher je nach Zielsetzung an die Wissenschaftler des Forschungsgebiets, teilnehmenden Unternehmen und Institute, Investoren oder andere gerichtet ist (und auch in verschiedenen Ausführungen für verschiedene Zielgruppen vorliegen kann) [1,2]. 3 Sammeln und Analysieren der Daten Allgemeine Prinzipien bei dem Sammeln von Daten sind laut [2]: Das Verwenden mehrerer Datenquellen (sowie das Triangulieren der Daten), das Erstellen einer Datenbank für die Fallstudie, das Validieren der gesammelten Daten und dem Aufrechterhalten einer Beweiskette. 3.1 Datenquellen Besonders hervorgehoben wird in der Literatur die Pluralität der Datenquellen, und in [5] wird zwischen den Arten und auch der Qualität der Quellen noch ex- plizit unterschieden. Als sogenannte Quellen ersten Grades (first degree) werden
4. 4.

   die direkten Kontaktmöglichkeiten eines Forschers mit den Studienteilnehmern beschrieben, z.B.

   Interviews oder direkte Beobachtungen (observations), wel- che qualitative Daten liefern und daher aufwändig in der Analyse sind. Quellen zweiten Grades beinhalten indirekten Zugriff auf nicht verarbeitete, meist quan- titative Daten (Archivdaten, archival records), z.B. Verwendungs-Protokolle von Software. Quellen dritten Grades sind schon analysierte, zusammengestellte Da- tensätze, wie beispielsweise Berichte aus Zeiterfassungen oder Spezifikationen. Im Folgenden soll exemplarisch auf Interviews und direkte Beobachtungen ein- gegangen werden, weitere Datenquellen werden ausführlich in [5] behandelt. Interviews haben den Vorteil, dass sie je nach Anforderung unterschiedlich ge- staltet sein können. So kann zwischen unstrukturierten, teilweise-strukturierten und strukturierten Interviews unterschieden werden, wobei bei Ersterem der Be- fragte den Verlauf des Gesprächs bestimmt und bei Letzterem die Fragen (und ggf. mögliche Antworten) im Vorhinein festgelegt wurden (im Stil einer Umfrage) [1,2]. Da eine direkte Interaktion zwischen Forscher und Teilnehmer stattfindet, bieten Interviews viele Möglichkeiten, zu bestimmten Aspekte der Studie gezielt Fragen zu stellen, Kompetenzen auszunutzen und auch bisher nicht beachtete Perspektiven mitgeteilt zu bekommen. Der Aufwand von Interviews ist jedoch sehr hoch, da zu der Interview-Dauer (z.B. 60-90 Minuten) Audio-Mitschnitte, Transkriptionen und ggf. Nachfolge-Termine berücksichtigt werden müssen [2,4]. »Direkte Beobachtung« ist eine einfache Methode, um Daten zu sammeln, bei der Beobachter dem Teilnehmer bei einer Aktivität oder für einen bestimmten Zeitraum zusieht und notiert, was der Teilnehmer tut. Vorteile sind schnelle Ergebnisse ohne nachträglich viel Aufwand zu erzeugen, jedoch ist es besonders in der Software-Entwicklung schwer, nur durch Beobachtung nachvollziehen zu können, was der zu Beobachtende genau macht. Um das zu umgehen, kann statt der reinen Beobachtung auch das so genannte think-aloud protocol angewendet werden, bei welchem der Teilnehmer seine Gedanken und Tätigkeiten versucht auszusprechen [1]. 3.2 Analyse der Daten Bei der Daten-Analyse muss zwischen quantitativen und qualitativen Daten un- terschieden werden [1]. Quantitative Daten basieren auf konsistenten Ansprü- chen (d.h. es ist nicht möglich, eine quantitative Frage in einer Umfrage im Verlauf der Studie zu ändern), ausreichend große Stichproben und lassen sich an Hand von statistischen Methoden auswerten, z.B. durch Durchschnittswerte, Standardabweichungen, Diagramme und Analyse von Korrelationen [1,5]. Die Analyse von qualitativen Daten ist im Vergleich zu der von quantitati- ven Daten umfangreicher, jedoch für flexible Forschungsmethoden wie Fallstu- dien unerlässlich. Hierzu gehört auch das ständige Analysieren von Daten schon im Verlauf der Datenerhebung und der Aktualisierung der Materialien zur Da- tenerhebung (z.B. Interview-Fragen) auf Grund von neuen Erkenntnissen. Um Befangenheit einzelner Forscher zu unterdrücken, sollte die Analyse immer von mehreren Personen durchgeführt werden [1].
5. 5.

   Je nach Ziel der Studie (erforschend oder erklärend), kann die

   Analyse dazu verwendet werden, eine These zu erzeugen oder eine schon vorhandene These (z.B. eine vorher erzeugte) zu bestätigen oder zu widerlegen, an Hand der For- schungsfragen und Ansprüche, welche in der Planungs-Phase spezifiziert wurden [1]. Weiterführende Quellen zu Kodierung-Methodiken und anderen systemati- schen Analyse-Verfahren qualitativer Daten werden in [1] und [5] referenziert. Die Ergebnisse der Analyse sind abschließender Bestandteil des Forschungs- berichts und sollen nachvollziehbar und mit Verweisen auf die eigentlichen Da- ten (die z.B. vollständig oder angemessen zusammengefasst im Anhang zu finden sind oder zitiert werden) im Stile einer Beweiskette präsentiert werden. Anschlie- ßend soll in einer Schlussbemerkung der Forscher die Auswirkung der Ergebnisse auf den Kontext des Studien-Gebiets beschrieben werden. Der finale Forschungsbericht der Fallstudie (report) ist die öffentliche Reprä- sentation der Studie. Er kann auf verschiedene Weisen strukturiert sein, z.B. linear, vergleichend (bei mehreren Fallstudien) oder chronologisch. Sollten ver- trauliche Daten gesammelt worden sein, müssen diese in einem öffentlichen Be- richt verschleiert oder entfernt werden [1]. 4 Fazit Fallstudien sind eine erprobte und umfangreiche Forschungsmethode, welche Phänomene in ihrem natürlichen Kontext betrachten und unter anderem des- wegen für das Gebiet der Software-Entwicklung geeignet sind. Sie werden über verschiedene Phasen durchgeführt und bieten durch systematische Analyse ge- sammelter Daten abschließend einen genauen Einblick in die betrachtete The- matik, wobei Einsichten sowohl erlangt wie auch analysiert werden können. Es existieren verschiedene, sich jedoch gut ergänzende Sammlungen an Richtlinien, welche eine kontrollierte und erfolgreiche Vorgehensweise ermöglichen. Als ab- schließende Übersicht zu dem gesamten Verlauf der besprochenen Phasen sei hier auf die Checklisten in Anhang A in [1] sowie auf Abbildung 1 in [2] verwiesen. Literatur 1. Per Runeson, Martin Höst. Guidelines for conducting and reporting case study research in software engineering. In: Empirical Software Engineering. Vol. 14, Issue 2. Seiten 131-164. Springer Netherlands 2009. doi:10.1007/s10664-008-9102-8. 2. J.M. Verner, J. Sampson, V. Tosic, N.A. Abu Bakar, B.A. Kitchenham. Guidelines for industrially-based multiple case studies in software engineering. In: Proceedings of the Third International Conference on Research Challenges in Infor- mation Science, 2009. Seiten 313–324. doi:10.1109/RCIS.2009.5089295. 3. B.A. Kitchenham, S.L. Pfleeger, L.M. Pickard, P.W. Jones, D.C. Hoag- lin, K. El Emam, J. Rosenberg. Preliminary guidelines for empirical research in software engineering. In: IEEE Transactions on Software Engineering 28 (8), Seiten 721–734, 2002. doi:10.1109/TSE.2002.1027796.
6. 6.

   4. Z. Racheva, M. Daneva, A. Sikkel, R. Wiering, a.

   Herrmann. Do we Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In: Proceedings of 18th IEEE International Requirements Engi- neering Conference (RE 10), Sep. 2010. Seiten 147-156. IEEE 2010, Australia. doi:10.1109/RE.2010.27. 5. T.C. Lethbridge, S.E. Sim, J. Singer. Studying software engineers: data collec- tion techniques for software field studies. Empirical Software Engineering, 10, Seiten 311–341, 2005. doi:10.1007/s10664-005-1290-x.