Richtlinien für Fallstudien in der Software-Entwicklung

• etwa 1.900 Worte

Dies ist eine für das Modul “Techniken des wissenschaftlichen Arbeitens” meines Informatik-Studiums verfasste Arbeit.

Fallstudien sind umfangreiche empirische Untersuchungen, welche in dem natürlichen Umfeld des Studiengebiets durchgeführt werden. Um Fallstudien erfolgreich im Bereich der Software-Entwicklung betreiben zu können, sollen bestimmte Richtlinien und Vorgehensweisen vorgestellt werden. Diese Arbeit richtet sich an Neulinge in diesem Bereich, die einen Überblick über die Thematik erhalten wollen.

Inhalts­ver­zeich­nis

Ein­lei­tung

Die Fall­stu­die (case study) ist eine For­schungs­me­thode, wel­che auf empi­ri­sche Weise mit­tels meh­re­rer qua­li­ta­ti­ver wie auch quan­ti­ta­ti­ver Daten­quel­len ein­zelne Phä­no­mene (pheno­mena) unter­sucht. Im Gegen­satz zu klas­si­schen Expe­ri­men­ten wer­den diese nicht in einer abge­schlos­se­nen wis­sen­schaft­li­chen Umge­bung betrach­tet, son­dern in dem jewei­li­gen natür­li­chen Umfeld [1].

Fall­stu­dien kön­nen ver­schie­de­nen Zwe­cken die­nen. In [1] und [2] wird zwi­schen erfor­schen­den (explo­ra­tory), beschrei­ben­den (descrip­tive), erklä­ren­den (expla­na­tory) und ver­bes­sern­den bzw. aus­wer­ten­den (impro­ving bzw. eva­lua­tory) Fall­stu­dien unter­schie­den. Fall­stu­dien sind abzu­gren­zen von sta­tis­ti­schen Erhe­bun­gen bzw. Umfra­gen, Expe­ri­men­ten und anwen­dungs­be­zo­ge­nen For­schun­gen.

Diese Eigen­schaf­ten füh­ren dazu, dass Fall­stu­dien in rich­ti­ger Anwen­dung tie­fere Ein­bli­cke und bes­se­res Ver­ständ­nis zu dem unter­such­ten Phä­no­men ermög­li­chen. Die rich­tige Durch­füh­rung ist jedoch von erheb­li­cher Bedeu­tung, da ansons­ten die For­schungs­er­geb­nisse von den Ein­drü­cken und Annah­men der For­scher gefärbt, schlecht auf all­ge­mei­nere The­sen über­trag­bar oder wenig aus­sa­ge­kräf­tig sein kön­nen. Unter ande­rem aus die­sem Grund sind in dem Bereich der Soft­ware-Ent­wick­lung Fall­stu­dien im Ver­gleich zu ande­ren wis­sen­schaft­li­chen Fel­dern zur Zeit noch unter­re­prä­sen­tiert und wer­den trotz stei­gen­der Aner­ken­nung in vie­len Fäl­len nicht in ange­mes­se­nem Umfang durch­ge­führt [1].

Die Quel­len [1], [2] und [3] stel­len alle­samt Kon­zepte und Richt­li­nien zur Durch­füh­rung von Fall­stu­dien im Bereich der Soft­ware-Ent­wick­lung vor, wel­che sich in ihrem abs­trak­ten Auf­bau nicht gra­vie­rend unter­schei­den. So steht zu Beginn der For­schungs­ar­beit das sorg­fäl­tige Pla­nen der Fall­stu­die, zu wel­chem u.a. die Bestim­mung der For­schungs­ziele und die Aus­wahl der Fall­stu­dien gehört, soll­ten meh­rere durch­ge­führt wer­den und zur Option ste­hen. Dar­auf folgt die Vor­be­rei­tungs-Phase, wo neben dem Bear­bei­ten von admi­nis­tra­ti­ven Auf­ga­ben auch die kon­kre­ten For­schungs­fra­gen und die Metho­den zum Sam­meln und Ver­wal­ten von Daten bestimmt wer­den. Das Erlan­gen der Daten (Bewei­sen, evi­dence) selbst aus ver­schie­de­nen Quel­len, von denen einige exem­pla­risch vor­ge­stellt wer­den, wird gefolgt von der Ana­lyse sel­bi­ger. Über den gesam­ten Ver­lauf der Fall­stu­die hin­weg sollte der For­schungs­be­richt zur Stu­die stets ergänzt und aktua­li­siert wer­den, sodass er den Ver­lauf der Fall­stu­die wider­spie­gelt und mit dem Ein­fü­gen der Ana­lyse-Ergeb­nisse und deren Bezug auf die For­schungs­fra­gen fina­li­siert wer­den kann.

Pla­nen und Vor­be­rei­ten von Fall­stu­dien

Zu Beginn der For­schung soll nach [2] und [3] geprüft wer­den, wel­che Fall­stu­dien ange­mes­sen sind (soll­ten meh­rere Stu­dien zusam­men durch­ge­führt wer­den), indem neben umfang­rei­che­rer Recher­che zu dem spe­zi­el­len Fall auch unter­sucht wird, ob die zu stel­len­den For­schungs­fra­gen durch eine Fall­stu­die beant­wor­tet wer­den kön­nen. Dies trifft vor allem auf Fra­gen nach dem Grund und der Art und Weise, wie auch bei ver­glei­chen­den (meh­re­ren) Fall­stu­dien zu.

Das Pla­nen der Fall­stu­die selbst wird in [1] dadurch spe­zi­fi­ziert, dass ver­schie­dene Ent­schei­dun­gen getrof­fen wer­den, wel­che die Fall­stu­die defi­nie­ren. So soll hier das Ziel[1], das zu unter­su­chende Phä­no­men bzw. der Fall[2], die Refe­renz-Theo­rie bzw. -Per­spek­tive[3], die zu stel­len­den For­schungs­fra­gen[4], sowie die Quel­len der Daten und Metho­den zum Sam­meln der­sel­ben bestimmt wer­den.

Nach Bestim­mung die­ser Ent­schei­dun­gen sieht [2] (vgl. Abschnitt IV) eine detail­lier­tere Aus­ar­bei­tung der grund­le­gen­den Merk­male der Fall­stu­die vor, wobei beson­ders Wert auf die Aus­wert­bar­keit der For­schungs­fra­gen und die Spe­zia­li­sie­rung der Stu­die gelegt wird. Dazu sol­len z.B. aus den For­schungs­fra­gen For­schungs-Behaup­tun­gen (rese­arch pro­po­si­ti­ons oder spä­ter hypo­the­ses) erzeugt wer­den, wel­che in der Stu­die wider­legt oder bestä­tigt wer­den. Auch soll bestimmt wer­den, wie die Ergeb­nisse zu mes­sen sind (z.B. Zeit­ge­winne oder die Ein­fach­heit der Benut­zung) und wie auf Basis des­sen die qua­li­ta­ti­ven Daten zu ana­ly­sie­ren sind.

Im Anschluss daran soll bestimmt wer­den, wel­che Schau­plätze oder ein­zelne Per­so­nen als Teil­neh­mer gesucht wer­den. Dazu sind ver­schie­dene Aus­wahl­kri­te­rien und Ein­schrän­kun­gen (boun­da­ries) mög­lich. So wer­den z.B. ver­schie­dene Abtei­lun­gen eines Unter­neh­mens betrach­tet, wel­che mög­lichst ähn­lich Ergeb­nisse erzielt haben. Des wei­te­ren sol­len nur Mei­nun­gen von Per­so­nen/​Grup­pen unter­sucht wer­den, wel­che aus ers­ter Hand Erfah­run­gen mit der unter­such­ten Tech­no­lo­gie haben oder diese mit ent­wi­ckelt haben [2] [3].

Wer­den meh­rere (ver­glei­chende) Fall­stu­dien durch­ge­führt, so muss zudem bestimmt wer­den, wel­che Stu­dien über­haupt durch­ge­führt wer­den und außer­dem, ob eine Pilot-Stu­die zur Über­prü­fung der bis­her geplan­ten Maß­nah­men rea­li­siert wer­den soll [2].

Zur Vor­be­rei­tung auf die nächs­ten Phase soll in der Vor­be­rei­tungs-Phase wei­ter­hin bestimmt wer­den, auf wel­che Weise die Daten gesam­melt (ver­schie­dene Daten­quel­len, s.u.), gespei­chert, vali­diert und ver­gli­chen (bei ver­glei­chen­den Fall­stu­dien) wer­den sol­len. Außer­dem sol­len bestimmte Risi­ko­fak­to­ren ein­ge­schränkt wer­den, z.B. durch Ver­mei­den der Aus­wahl von Per­so­nen zum Tes­ten einer Tech­no­lo­gie, wel­che ent­we­der mit die­ser bereits ver­traut, oder dafür über­haupt nicht qua­li­fi­ziert sind [2].

Eine wei­tere wich­tige Auf­gabe der Pla­nungs­phase, die jedoch wäh­rend der sons­ti­gen Pla­nung aus­ge­führt wer­den kann und nicht von ihr abhängt, ist es, admi­nis­tra­tive Fra­gen zu klä­ren. So müs­sen in Zusam­men­ar­beit mit Unter­neh­men und ande­ren Insti­tu­tio­nen neben ter­min­li­chen und per­so­nel­len Ver­ein­ba­run­gen auch juris­ti­sche Fra­gen und sol­che im Bezug auf die Ver­trau­lich­keit der erho­be­nen Daten beant­wor­tet wer­den, von wel­chen unter ande­rem die Ver­öf­fent­li­chung des fina­len For­schungs­be­richts abhängt [2].

Das Stu­dien-Pro­to­koll (case study pro­to­col) wird zunächst als Samm­lung der bis­her getrof­fe­nen Ent­schei­dun­gen ange­legt und in den fol­gen­den Pha­sen durch wei­tere Kon­ven­tio­nen und gesam­melte Daten ergänzt, um den fina­len For­schungs­be­richt (report) zu for­men. Wie oben erwähnt, hat das frühe Anle­gen und ste­tige Erwei­tern des Pro­to­kolls die Vor­teile, dass die getrof­fe­nen Ent­schei­dun­gen stets gesam­melt zur Ver­fü­gun­gen ste­hen und dass den ein­zel­nen For­schern einen Über­blick über die zu sam­meln­den Daten gege­ben wird. Es ist hilf­reich, das Pro­to­koll extern gegen­le­sen zu las­sen, um Feh­ler und Inkon­sis­ten­zen zu ver­mei­den. Am Ende der Pla­nungs­phase soll das Pro­to­koll bzw. der Fall­stu­dien-Plan die gesamte vor­ge­se­hene Durch­füh­rung der Stu­die abde­cken und beschrei­ben. Beim Abschluss der Fall­stu­die liegt diese als voll­stän­di­ger For­schungs­be­richt vor, wel­cher je nach Ziel­set­zung an die Wis­sen­schaft­ler des For­schungs­ge­biets, teil­neh­men­den Unter­neh­men und Insti­tute, Inves­to­ren oder andere gerich­tet ist (und auch in ver­schie­de­nen Aus­füh­run­gen für ver­schie­dene Ziel­grup­pen vor­lie­gen kann) [1] [2].

Sam­meln und Ana­ly­sie­ren der Daten

All­ge­meine Prin­zi­pien bei dem Sam­meln von Daten sind laut [2]: Das Ver­wen­den meh­re­rer Daten­quel­len (sowie das Tri­an­gu­lie­ren der Daten), das Erstel­len einer Daten­bank für die Fall­stu­die, das Vali­die­ren der gesam­mel­ten Daten und dem Auf­recht­er­hal­ten einer Beweis­kette.

Daten­quel­len

Beson­ders her­vor­ge­ho­ben wird in der Lite­ra­tur die Plu­ra­li­tät der Daten­quel­len, und in [5] wird zwi­schen den Arten und auch der Qua­li­tät der Quel­len noch expli­zit unter­schie­den. Als soge­nannte Quel­len ers­ten Gra­des (first degree) wer­den die direk­ten Kon­takt­mög­lich­kei­ten eines For­schers mit den Stu­di­en­teil­neh­mern beschrie­ben, z.B. Inter­views oder direkte Beob­ach­tun­gen (obser­va­tions), wel­che qua­li­ta­tive Daten lie­fern und daher auf­wän­dig in der Ana­lyse sind. Quel­len zwei­ten Gra­des beinhal­ten indi­rek­ten Zugriff auf nicht ver­ar­bei­tete, meist quan­ti­ta­tive Daten (Archiv­da­ten, archi­val records), z.B. Ver­wen­dungs-Pro­to­kolle von Soft­ware. Quel­len drit­ten Gra­des sind schon ana­ly­sierte, zusam­men­ge­stellte Daten­sätze, wie bei­spiels­weise Berichte aus Zeit­er­fas­sun­gen oder Spe­zi­fi­ka­tio­nen. Im Fol­gen­den soll exem­pla­risch auf Inter­views und direkte Beob­ach­tun­gen ein­ge­gan­gen wer­den, wei­tere Daten­quel­len wer­den aus­führ­lich in [5] behan­delt.

Inter­views haben den Vor­teil, dass sie je nach Anfor­de­rung unter­schied­lich gestal­tet sein kön­nen. So kann zwi­schen unstruk­tu­rier­ten, teil­weise-struk­tu­rier­ten und struk­tu­rier­ten Inter­views unter­schie­den wer­den, wobei bei Ers­te­rem der Befragte den Ver­lauf des Gesprächs bestimmt und bei Letz­te­rem die Fra­gen (und ggf. mög­li­che Ant­wor­ten) im Vor­hin­ein fest­ge­legt wur­den (im Stil einer Umfrage) [1] [2]. Da eine direkte Inter­ak­tion zwi­schen For­scher und Teil­neh­mer statt­fin­det, bie­ten Inter­views viele Mög­lich­kei­ten, zu bestimm­ten Aspekte der Stu­die gezielt Fra­gen zu stel­len, Kom­pe­ten­zen aus­zu­nut­zen und auch bis­her nicht beach­tete Per­spek­ti­ven mit­ge­teilt zu bekom­men. Der Auf­wand von Inter­views ist jedoch sehr hoch, da zu der Inter­view-Dauer (z.B. 60-90 Minu­ten) Audio-Mit­schnitte, Tran­skrip­tio­nen und ggf. Nach­folge-Ter­mine berück­sich­tigt wer­den müs­sen [2] [4].

»Direkte Beob­ach­tung« ist eine ein­fa­che Methode, um Daten zu sam­meln, bei der Beob­ach­ter dem Teil­neh­mer bei einer Akti­vi­tät oder für einen bestimm­ten Zeit­raum zusieht und notiert, was der Teil­neh­mer tut. Vor­teile sind schnelle Ergeb­nisse ohne nach­träg­lich viel Auf­wand zu erzeu­gen, jedoch ist es beson­ders in der Soft­ware-Ent­wick­lung schwer, nur durch Beob­ach­tung nach­voll­zie­hen zu kön­nen, was der zu Beob­ach­tende genau macht. Um das zu umge­hen, kann statt der rei­nen Beob­ach­tung auch das so genannte think-aloud pro­to­col ange­wen­det wer­den, bei wel­chem der Teil­neh­mer seine Gedan­ken und Tätig­kei­ten ver­sucht aus­zu­spre­chen [1].

Ana­lyse der Daten

Bei der Daten-Ana­lyse muss zwi­schen quan­ti­ta­ti­ven und qua­li­ta­ti­ven Daten unter­schie­den wer­den [1]. Quan­ti­ta­tive Daten basie­ren auf kon­sis­ten­ten Ansprü­chen (d.h. es ist nicht mög­lich, eine quan­ti­ta­tive Frage in einer Umfrage im Ver­lauf der Stu­die zu ändern), aus­rei­chend große Stich­pro­ben und las­sen sich an Hand von sta­tis­ti­schen Metho­den aus­wer­ten, z.B. durch Durch­schnitts­werte, Stan­dard­ab­wei­chun­gen, Dia­gramme und Ana­lyse von Kor­re­la­tio­nen [1] [5].

Die Ana­lyse von qua­li­ta­ti­ven Daten ist im Ver­gleich zu der von quan­ti­ta­ti­ven Daten umfang­rei­cher, jedoch für fle­xi­ble For­schungs­me­tho­den wie Fall­stu­dien uner­läss­lich. Hierzu gehört auch das stän­dige Ana­ly­sie­ren von Daten schon im Ver­lauf der Daten­er­he­bung und der Aktua­li­sie­rung der Mate­ria­lien zur Daten­er­he­bung (z.B. Inter­view-Fra­gen) auf Grund von neuen Erkennt­nis­sen. Um Befan­gen­heit ein­zel­ner For­scher zu unter­drü­cken, sollte die Ana­lyse immer von meh­re­ren Per­so­nen durch­ge­führt wer­den [1].

Je nach Ziel der Stu­die (erfor­schend oder erklä­rend), kann die Ana­lyse dazu ver­wen­det wer­den, eine These zu erzeu­gen oder eine schon vor­han­dene These (z.B. eine vor­her erzeugte) zu bestä­ti­gen oder zu wider­le­gen, an Hand der For­schungs­fra­gen und Ansprü­che, wel­che in der Pla­nungs-Phase spe­zi­fi­ziert wur­den [1]. Wei­ter­füh­rende Quel­len zu Kodie­rung-Metho­di­ken und ande­ren sys­te­ma­ti­schen Ana­lyse-Ver­fah­ren qua­li­ta­ti­ver Daten wer­den in [1] und [5] refe­ren­ziert.

Die Ergeb­nisse der Ana­lyse sind abschlie­ßen­der Bestand­teil des For­schungs­be­richts und sol­len nach­voll­zieh­bar und mit Ver­wei­sen auf die eigent­li­chen Daten (die z.B. voll­stän­dig oder ange­mes­sen zusam­men­ge­fasst im Anhang zu fin­den sind oder zitiert wer­den) im Stile einer Beweis­kette prä­sen­tiert wer­den. Anschlie­ßend soll in einer Schluss­be­mer­kung der For­scher die Aus­wir­kung der Ergeb­nisse auf den Kon­text des Stu­dien-Gebiets beschrie­ben wer­den.

Der finale For­schungs­be­richt der Fall­stu­die (report) ist die öffent­li­che Reprä­sen­ta­tion der Stu­die. Er kann auf ver­schie­dene Wei­sen struk­tu­riert sein, z.B. linear, ver­glei­chend (bei meh­re­ren Fall­stu­dien) oder chro­no­lo­gisch. Soll­ten ver­trau­li­che Daten gesam­melt wor­den sein, müs­sen diese in einem öffent­li­chen Bericht ver­schlei­ert oder ent­fernt wer­den [1].

Fazit

Fall­stu­dien sind eine erprobte und umfang­rei­che For­schungs­me­thode, wel­che Phä­no­mene in ihrem natür­li­chen Kon­text betrach­ten und unter ande­rem des­we­gen für das Gebiet der Soft­ware-Ent­wick­lung geeig­net sind. Sie wer­den über ver­schie­dene Pha­sen durch­ge­führt und bie­ten durch sys­te­ma­ti­sche Ana­lyse gesam­mel­ter Daten abschlie­ßend einen genauen Ein­blick in die betrach­tete The­ma­tik, wobei Ein­sich­ten sowohl erlangt wie auch ana­ly­siert wer­den kön­nen. Es exis­tie­ren ver­schie­dene, sich jedoch gut ergän­zende Samm­lun­gen an Richt­li­nien, wel­che eine kon­trol­lierte und erfolg­rei­che Vor­ge­hens­weise ermög­li­chen. Als abschlie­ßende Über­sicht zu dem gesam­ten Ver­lauf der bespro­che­nen Pha­sen sei hier auf die Check­lis­ten in Anhang A in [1] sowie auf Abbil­dung 1 in [2] ver­wie­sen.


Lite­ra­tur

  1. Per Rune­son, Mar­tin Höst.
    Gui­de­li­nes for con­duc­ting and reporting case study rese­arch in soft­ware engi­nee­ring.
    In: Empi­ri­cal Soft­ware Engi­nee­ring. Vol. 14, Issue 2. Sei­ten 131-164. Sprin­ger Nether­lands 2009.
    doi:10.1007/​s10664-008-9102-8.

  2. J.M. Ver­ner, J. Samp­son, V. Tosic, N.A. Abu Bakar, B.A. Kit­chen­ham.
    Gui­de­li­nes for indus­tri­ally-based mul­ti­ple case stu­dies in soft­ware engi­nee­ring.
    In: Pro­cee­dings of the Third Inter­na­tio­nal Con­fe­rence on Rese­arch Chal­len­ges in Infor­ma­tion Sci­ence, 2009. Sei­ten 313–324.
    doi:10.1109/​RCIS.2009.5089295.

  3. B.A. Kit­chen­ham, S.L. Pflee­ger, L.M. Pickard, P.W. Jones, D.C. Hoag­lin, K. El Emam, J. Rosen­berg.
    Preli­mi­nary gui­de­li­nes for empi­ri­cal rese­arch in soft­ware engi­nee­ring.
    In: IEEE Tran­sac­tions on Soft­ware Engi­nee­ring 28 (8), Sei­ten 721–734, 2002.
    doi:10.1109/​TSE.2002.1027796.

  4. Z. Racheva, M. Daneva, A. Sik­kel, R. Wie­ring, a. Herr­mann.
    Do We Know Enough about Requi­re­ments Prio­ri­tiza­t­ion in Agile Pro­jects: Insights from a Case Study.
    In: Pro­cee­dings of 18th IEEE Inter­na­tio­nal Requi­re­ments Engi­nee­ring Con­fe­rence (RE 10), Sep. 2010. Sei­ten 147-156. IEEE 2010, Aus­tra­lia.
    doi:10.1109/​RE.2010.27.

  5. T.C. Leth­bridge, S.E. Sim, J. Sin­ger.
    Stu­dy­ing soft­ware engi­neers: data collec­tion tech­ni­ques for soft­ware field stu­dies.
    Empi­ri­cal Soft­ware Engi­nee­ring, 10, Sei­ten 311–341, 2005.
    doi:10.1007/​s10664-005-1290-x.


  1. objec­tive, z.B. Erfor­schen, beschrei­ben oder erklä­ren (s.o), warum eine Tech­no­lo­gie zu einer beschleu­nig­ten Soft­ware-Ent­wick­lung führt.

  2. case, z.B. ein Soft­ware-Pro­jekt oder eine bestimmte Tech­no­lo­gie

  3. theory (frame of refe­rence), z.B. die Annahme, die Tech­no­lo­gie ermög­li­che eine fle­xi­blere Soft­ware-Ent­wick­lung

  4. rese­arch ques­ti­ons, z.B. »Ändert sich der Ent­wick­lungs-Ver­lauf bei Ver­wen­dung die­ser Tech­no­lo­gie?«