張 文 李自強(qiáng) 杜宇航 趙博揚(yáng)
(北京化工大學(xué)大數(shù)據(jù)科學(xué)研究中心 北京 100029)
?
OSDR:一種開源軟件的缺陷修復(fù)人推薦方法
張 文 李自強(qiáng) 杜宇航 趙博揚(yáng)
(北京化工大學(xué)大數(shù)據(jù)科學(xué)研究中心 北京 100029)
對于大型開源軟件項(xiàng)目來說,用戶提交了海量缺陷報(bào)告,人工分發(fā)缺陷時(shí)會(huì)出現(xiàn)大量的錯(cuò)誤分配。提出OSDR(Open Software Developer Recommendation)方法通過計(jì)算新缺陷報(bào)告和歷史缺陷報(bào)告之間的文本相似度,基于K最近鄰算法得到相似度最高的K個(gè)歷史缺陷報(bào)告及其對應(yīng)的修復(fù)人列表,再基于頻率和社交網(wǎng)絡(luò)圖的各項(xiàng)指標(biāo)對開發(fā)者專業(yè)能力進(jìn)行評價(jià)。從Mozilla Firefox 缺陷庫中采集真實(shí)實(shí)驗(yàn)數(shù)據(jù),比較不同社交網(wǎng)絡(luò)指標(biāo)在推薦修復(fù)人時(shí)的準(zhǔn)確率與召回率。結(jié)果表明,推薦性能最高的指標(biāo)是頻率和出度,其準(zhǔn)確率大約在0.6左右;Betweenness和Closeness的推薦效果最差;度、入度以及PageRank推薦效果良好。
開源軟件 缺陷報(bào)告 修復(fù)人推薦 社交網(wǎng)絡(luò)分析
開源軟件是源碼向公眾開放的一類軟件,其源碼的修改不受許可證的限制。隨著開源軟件的規(guī)模和復(fù)雜程度不斷增加,不可避免會(huì)有眾多的缺陷存在。缺陷會(huì)給用戶帶來使用上的不便,對軟件的可靠性和可用性都帶來顯著影響,其數(shù)量也是評價(jià)軟件質(zhì)量的重要因素。
大型開源軟件項(xiàng)目如Apache、Eclipse和Mozilla等均采用開放缺陷跟蹤系統(tǒng)來管理軟件缺陷,為用戶提交缺陷報(bào)告和開發(fā)者解決軟件缺陷提供了方便。在傳統(tǒng)的方式中,軟件缺陷報(bào)告在缺陷追蹤系統(tǒng)中被人工分配給開發(fā)者進(jìn)行修復(fù)。在各個(gè)大型的開源項(xiàng)目開發(fā)的早期階段,簡單的修復(fù)人推薦機(jī)制依然能夠滿足需求,但是隨著分配任務(wù)量的大幅度增加,任務(wù)對于一個(gè)人來說過于繁重。例如,對于開源項(xiàng)目Mozilla Firefox來說,每天大約有300多個(gè)需要分配的新缺陷報(bào)告被提交,這大大超過了Mozilla項(xiàng)目中的缺陷分配人員所能承受的任務(wù)量,平均需要40天才能把一個(gè)bug分配給它的第一個(gè)修復(fù)人。正是因?yàn)槭止と毕莘峙溥^程的復(fù)雜性,很多缺陷報(bào)告會(huì)被誤分配給不適合修復(fù)它的開發(fā)者,還要重新進(jìn)行缺陷分配,這反過來又增加了缺陷修復(fù)的整體時(shí)間。巨大的工作量和易錯(cuò)性成為了整個(gè)系統(tǒng)的瓶頸,嚴(yán)重影響了軟件開發(fā)的效率,增大了軟件項(xiàng)目的成本[1]。不僅如此,缺陷分配人員需要充分了解開發(fā)任務(wù)、項(xiàng)目方向、團(tuán)隊(duì)結(jié)構(gòu)、開發(fā)者的經(jīng)歷和等級,以及其他與該缺陷報(bào)告相關(guān)的信息才能做出準(zhǔn)確的缺陷分配。除此之外,傳統(tǒng)缺陷跟蹤系統(tǒng)的運(yùn)行機(jī)制會(huì)導(dǎo)致大量的缺陷報(bào)告分配給不具備相應(yīng)修復(fù)能力的開發(fā)者,進(jìn)而導(dǎo)致大量缺陷報(bào)告的再分配。一個(gè)開發(fā)者的專業(yè)知識有限,而一個(gè)缺陷可能不止涉及一個(gè)專業(yè)。這些都會(huì)大大的降低缺陷修復(fù)的效率。
本文提出一種名為OSDR的開源軟件缺陷的修復(fù)人推薦方法。該方法采用自動(dòng)化的方式,基于開源項(xiàng)目的開放缺陷庫中的已經(jīng)被解決的缺陷報(bào)告,以及開源社區(qū)中眾多的開發(fā)者提交的修復(fù)評論,對新被提交的缺陷進(jìn)行修復(fù)人推薦。當(dāng)一個(gè)新的缺陷報(bào)告被提交到缺陷庫中后,該方法計(jì)算新缺陷報(bào)告和歷史缺陷報(bào)告之間的文本相似度,得到K個(gè)與新缺陷報(bào)告相似度最高的歷史缺陷報(bào)告。進(jìn)而提取出這些歷史缺陷報(bào)告對應(yīng)的開發(fā)者,并據(jù)此建立社交網(wǎng)絡(luò)圖,最后使用7種指標(biāo)對開發(fā)者的專業(yè)能力評級,從而推薦出合適的缺陷修復(fù)人。
現(xiàn)有的缺陷報(bào)告分配方法可以分為兩類:第一類是將缺陷修復(fù)人推薦問題看作為一種分類問題,這類方法首先對開發(fā)者的興趣或?qū)I(yè)領(lǐng)域進(jìn)行分類,然后將新提交的缺陷報(bào)告按照類別匹配給開發(fā)者作為缺陷修復(fù)人。第二類方法是通過計(jì)算模型得到新提交的缺陷報(bào)告與歷史缺陷報(bào)告之間的相似度,然后對相似的歷史缺陷報(bào)告中的開發(fā)人員進(jìn)行能力評級,最后將能力較高的開發(fā)人員推薦為該新缺陷報(bào)告的修復(fù)人。
在上述第一類方法的研究中,Jifeng Xuan等[2]使用了社交網(wǎng)絡(luò)圖的方法建立一種缺陷修復(fù)人的分析機(jī)制。通過修復(fù)人在論壇中的評論,此方法對修復(fù)人的專業(yè)能力進(jìn)行分類,并且為其設(shè)置能力標(biāo)簽。CosTRIAGE[3]使用LDA(文檔主題生成模型)來驗(yàn)證缺陷報(bào)告的主題并且對修復(fù)人畫像進(jìn)行建模,以此計(jì)算修復(fù)人對相關(guān)缺陷的平均修復(fù)水平。Olga Baysal等[4]提出了一種缺陷報(bào)告自動(dòng)分配的框架,該框架能夠根據(jù)開發(fā)者的開發(fā)歷史推斷出其專家級別和專業(yè)方向。Matter等[5]提出了一種基于源代碼的經(jīng)驗(yàn)?zāi)P鸵员容^修復(fù)人的貢獻(xiàn)經(jīng)歷和缺陷報(bào)告的處理,之后該模型推薦新缺陷報(bào)告與歷史缺陷報(bào)告之間貢獻(xiàn)經(jīng)歷語義相似度最高的修復(fù)人作為最終推薦人。John Anvik等[6-7]提出了一種自動(dòng)推薦程序軟件,該軟件能夠提供一種包含之前已修復(fù)的缺陷報(bào)告信息的模型,進(jìn)而形成一種能夠推薦項(xiàng)目修復(fù)人專業(yè)程度的算法。
在上述第二類方法的研究中,Tao Zhang等[8]首先抽取出與新缺陷報(bào)告相似的歷史報(bào)告,接下來建立社交網(wǎng)絡(luò)圖代表修復(fù)人之間的關(guān)系,所涉及的因素包括修復(fù)時(shí)間和來自相似歷史文件的修復(fù)人。最后在候選者中,通過DRA修復(fù)人排行算法來推薦修復(fù)人。Zhang等[9]提出的混合式缺陷分類策略可以優(yōu)化修復(fù)人推薦進(jìn)程。在判斷新舊缺陷報(bào)告相似性階段,該策略選擇了一元平滑模型,同時(shí)結(jié)合了機(jī)率模型和經(jīng)驗(yàn)?zāi)P?。DRETOM[10]使用歷史修復(fù)記錄來建立模型。對于每一個(gè)缺陷報(bào)告,其自然語言內(nèi)容被提取和預(yù)處理來進(jìn)行建模,相應(yīng)的修復(fù)人也被提取出,兩者的雙邊聯(lián)系模型得到建立。DevRec[11]由缺陷分析和修復(fù)人分析組成。在缺陷分析中,根據(jù)新的缺陷報(bào)告與舊的缺陷報(bào)告的相似性,將其分類。之后,根據(jù)每個(gè)修復(fù)人已修復(fù)的缺陷報(bào)告的特征計(jì)算修復(fù)人與該新被提交的缺陷報(bào)告的親和度。Kanwal等[12]提出了一種基于支持向量機(jī)和樸素貝葉斯算法的缺陷報(bào)告優(yōu)先級預(yù)測分類算法,同時(shí)探尋了不同的缺陷屬性對缺陷優(yōu)先級分類的重要性。Servant等[13]提出了一種新的基于錯(cuò)誤定位技術(shù)和軟件源碼歷史的缺陷修復(fù)人智能推薦技術(shù)。該技術(shù)拋棄了原始的缺陷報(bào)告的文本匹配,能夠定位缺陷,根據(jù)歷史記錄來確定修復(fù)人。
在上述兩種方法中,缺陷報(bào)告中的文本描述的質(zhì)量和缺陷修復(fù)人專業(yè)領(lǐng)域?qū)τ谌毕萃扑]的結(jié)果是決定性的因素。缺陷報(bào)告質(zhì)量高的缺陷會(huì)很容易的推薦,而缺陷報(bào)告質(zhì)量低的缺陷則難以及時(shí)推薦。由于不同的缺陷提交者對缺陷有不同的理解,且書寫風(fēng)格也不盡相同,有些缺陷描述會(huì)含糊不清。往往一個(gè)缺陷的出現(xiàn)涉及多個(gè)專業(yè)領(lǐng)域,一個(gè)缺陷修復(fù)人的專業(yè)知識有限,這些都導(dǎo)致很難較快較好地完成缺陷修復(fù)。
2.1 問題描述
為了方便描述,OSDR方法涉及的主要概念包括文檔,以及缺陷修復(fù)相關(guān)的開發(fā)者有序集合。下面分別給出它們在本文中的定義。
定義1歷史缺陷報(bào)告文檔:歷史缺陷報(bào)告文檔是指在缺陷庫中已經(jīng)被完成缺陷修復(fù)任務(wù)的缺陷報(bào)告,用bughis表示。
定義2新缺陷報(bào)告文檔:新缺陷報(bào)告文檔bugnew是指新增的被提交、被確認(rèn)為軟件缺陷的報(bào)告。
定義3相似的歷史報(bào)告:相似的歷史報(bào)告bugsim是指利用新提交的缺陷報(bào)告和歷史缺陷庫,選用KNN算法,找出相似的缺陷報(bào)告,以便找到其對應(yīng)的開發(fā)者。
定義4歷史缺陷修復(fù)人:對于每個(gè)歷史缺陷報(bào)告bughis, 它的缺陷修復(fù)相關(guān)的開發(fā)者集合為devi(i=1,2,3,…)。
假定在一個(gè)開源項(xiàng)目中有n個(gè)開發(fā)人員,并且在該項(xiàng)目的開放數(shù)據(jù)庫中具有m個(gè)歷史缺陷報(bào)告,每個(gè)缺陷報(bào)告都擁有一系列關(guān)于解決該缺陷報(bào)告的評論。這些評論是對該缺陷感興趣的開發(fā)者提出的。我們難以確定每個(gè)評論對缺陷修復(fù)的貢獻(xiàn),同時(shí)由于這些缺陷修復(fù)討論發(fā)生在這群開發(fā)者之間。因此,啟發(fā)式地我們認(rèn)為其中的所有開發(fā)者都為該缺陷修復(fù)做出了貢獻(xiàn),但是貢獻(xiàn)大小主要從發(fā)表評論的次數(shù)以及討論過程中形成的開發(fā)者交流網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)來反應(yīng)。
因此,我們可以將推薦缺陷修復(fù)相關(guān)問題描述為:針對一個(gè)新缺陷報(bào)告, 需要通過模型M來推薦一定數(shù)量的開發(fā)者,這些個(gè)開發(fā)者具備修復(fù)新缺陷報(bào)告的相關(guān)經(jīng)驗(yàn)知識并可能對該缺陷報(bào)告的解決作出貢獻(xiàn)。本文認(rèn)為在一個(gè)大型軟件項(xiàng)目中,缺陷修復(fù)是一種開發(fā)者群體協(xié)作行為,專注相同軟件模塊或相近模塊的開發(fā)者常常會(huì)形成群體。為了初步確定這一開發(fā)者群體,本文利用新提交的缺陷報(bào)告和歷史缺陷庫,選用KNN算法,找出與k個(gè)相似的缺陷報(bào)告,進(jìn)而找出背后的開發(fā)者們。
2.2OSDR方法原理
OSDR采用的總體結(jié)構(gòu)如圖1所示。當(dāng)一個(gè)新缺陷報(bào)告被提交到開放缺陷庫,OSDR首先計(jì)算新缺陷報(bào)告的描述和歷史缺陷報(bào)告的描述之間的文本相似性,基于KNN算法提取出一系列相似度高的歷史報(bào)告得到相似缺陷庫,從而找出其對應(yīng)的修復(fù)人。然后構(gòu)建修復(fù)人溝通網(wǎng)絡(luò),OSDR方法使用頻率和社交網(wǎng)絡(luò)圖各指標(biāo)對這些開發(fā)者們的專業(yè)能力進(jìn)行評級。最后相似歷史缺陷報(bào)告對應(yīng)的開發(fā)者中的具有較高專業(yè)度的開發(fā)者們將被推薦給這個(gè)新的缺陷,作為解決問題的修復(fù)人。
圖1 OSDR方法的整體結(jié)構(gòu)
1) 提取相似報(bào)告集:每個(gè)缺陷報(bào)告都含有預(yù)定義的屬性和自有格式的文本描述。在本文的方法里面,只有自由格式的文本描述被使用,文本描述包含了缺陷的關(guān)鍵字和對該缺陷報(bào)告的簡介。當(dāng)一個(gè)新的缺陷報(bào)告被提交的時(shí)候,首先利用文本向量空間模型將其轉(zhuǎn)換為成文本向量;然后OSDR方法在新的缺陷報(bào)告和眾多歷史缺陷之間計(jì)算它們之間的相似性;最后,對于給定的最為相似的歷史缺陷報(bào)告數(shù)目K,將具有最高相似性的K個(gè)歷史缺陷報(bào)告被從開放缺陷庫中提取出來,作為新缺陷的相似缺陷集。
2) 排行開發(fā)者專業(yè)度:得到了新的缺陷報(bào)告的相似報(bào)告集之后,就要進(jìn)而得到其對應(yīng)的開發(fā)者列表。同時(shí)這些開發(fā)者在相似報(bào)告集中的參與記錄可以被用來評價(jià)開發(fā)者在解決該缺陷方面的專業(yè)程度。本文的研究采用七種評價(jià)指標(biāo)來排行修復(fù)人的專業(yè)程度,第一個(gè)指標(biāo)是每個(gè)開發(fā)者在參與記錄中的出現(xiàn)頻率,另外六個(gè)是社交網(wǎng)路圖分析中的評價(jià)指標(biāo)。
當(dāng)使用頻率的時(shí)候,對于每個(gè)缺陷開發(fā)者,OSDR方法計(jì)算出他在相似的缺陷報(bào)告中的出現(xiàn)頻率,使用社交網(wǎng)絡(luò)圖的指標(biāo)時(shí)候,首先OSDR方法根據(jù)開發(fā)者的參與記錄生成一個(gè)社交網(wǎng)絡(luò)圖。在該方法中,生成社交網(wǎng)絡(luò)圖的規(guī)則如圖2所示。通過式(1)計(jì)算相似度,Sim(bugnew,bughis1)和Sim(bugnew,bughis2)是計(jì)算新的缺陷和各個(gè)歷史缺陷的相似性(這里舉兩個(gè)bughis1和bughis2的例子)。dev1等代表的是各個(gè)歷史缺陷報(bào)告中的所有開發(fā)者集合。箭頭的意義在于本文認(rèn)為評論靠后的開發(fā)者參考了評論在前的開發(fā)者的解決辦法。之后該方法采用度(degree),出度(out-degree),入度(in-degree),中心性(betweenness centrality),接近性(closeness centrality),佩奇排行(PageRank)來對網(wǎng)絡(luò)圖進(jìn)行分析。開發(fā)者出現(xiàn)的頻率是另外一個(gè)參考指標(biāo)。
(1)
圖2 社交網(wǎng)絡(luò)圖生成示例
本文利用JUNG(Java開源社交網(wǎng)絡(luò)圖框架)軟件生成的社交網(wǎng)絡(luò)圖如圖3所示,各個(gè)節(jié)點(diǎn)代表的是修復(fù)人的編號,其權(quán)重指的是缺陷報(bào)告之間的相似性。由圖可以直觀地從這個(gè)社交網(wǎng)絡(luò)圖中看到缺陷修復(fù)人之間的關(guān)系,同時(shí)也可以高效地使用degree等六種指標(biāo)進(jìn)行社交網(wǎng)絡(luò)圖節(jié)點(diǎn)重要性的評判節(jié)點(diǎn)重要性的評判。
圖3 OSDR方法生成的社交網(wǎng)絡(luò)圖
2.3 OSDR相關(guān)技術(shù)
本文介紹的OSDR方法,首先對數(shù)據(jù)做自然語言預(yù)處理。然后采用TF-IDF技術(shù)對自然語言文本進(jìn)行處理,來方便計(jì)算缺陷之間的相似度。之后運(yùn)用KNN算法找出k個(gè)相似的歷史缺陷。再確定其修復(fù)人。最后利用社交網(wǎng)絡(luò)圖分析來排序,得到結(jié)果。
(1) 自然語言預(yù)處理
文本預(yù)處理能夠完善數(shù)據(jù)的完整性,是數(shù)據(jù)挖掘過程中的重要階段。在該軟件中,正則表達(dá)式的應(yīng)用可以去除無意義的符號等數(shù)據(jù),也可以幫助研究人員提取符合一定格式的數(shù)據(jù),OSDR方法去除了對缺陷描述中的無意義的符號、噪聲數(shù)字和亂碼。
詞干提取是對文本進(jìn)行處理的重要環(huán)節(jié),在該軟件中,OSDR使用Porter英文詞干提取算法,該算法可以用來高效準(zhǔn)確還原英語時(shí)態(tài)、單復(fù)數(shù)和否定等變換詞的詞干,增加文檔間相似度計(jì)算的精確性。在停詞處理是去除文本中的無用的詞匯,本文采用常用的英文的停詞表 作為OSDR方法的去除停詞模板。
(2) 空間向量模型轉(zhuǎn)換
(3)K最近鄰算法
KNN(K最近鄰)算法是應(yīng)用最廣泛的分類算法之一,其原理是每個(gè)樣本都可以用它最接近的k個(gè)鄰居來代表。本文應(yīng)用KNN算法的核心思想來,即計(jì)算新產(chǎn)生的缺陷與缺陷庫中不同的缺陷報(bào)告的相似性,通過對比計(jì)算相似性,得到K個(gè)相似度最高的原有缺陷報(bào)告作為基礎(chǔ)[15],進(jìn)而提取其對應(yīng)的多個(gè)缺陷的開發(fā)者作為備選的修復(fù)人:{dev1,dev2,dev3,…}。OSDR方法使用夾角余弦來進(jìn)行文本相似性的計(jì)算,同時(shí)根據(jù)用戶對K的設(shè)定,來得出相似性最高的K個(gè)報(bào)告。同時(shí)從開放缺陷庫中提取出相應(yīng)的缺陷修復(fù)人列表。
(4) 社交網(wǎng)絡(luò)圖分析
社交網(wǎng)絡(luò)圖分析被用來分析社會(huì)學(xué),并且通常會(huì)用來分析一個(gè)社交系統(tǒng)成員之間的復(fù)雜的關(guān)系,目的通常都是解釋社交現(xiàn)象。社交網(wǎng)絡(luò)圖能夠展示出各個(gè)節(jié)點(diǎn)之間的聯(lián)系,可以用來評價(jià)修復(fù)人的專業(yè)度。社交網(wǎng)絡(luò)很早就被表示成圖的形式,其節(jié)點(diǎn)表示這社交角色,邊代表著角色之間的關(guān)系[16-17]。
社交網(wǎng)絡(luò)圖的功能就是通過修復(fù)人在網(wǎng)絡(luò)圖中的位置,排行它們的重要性。本文使用中心性這個(gè)概念,具有較高中心性的節(jié)點(diǎn)意味著在網(wǎng)絡(luò)圖中更高的重要性。在本研究中,度、出度、入度、PageRank,Betweenness,Closeness被用來評價(jià)節(jié)點(diǎn)重要性。
3.1 實(shí)驗(yàn)設(shè)定
本文使用精度(precision)和查全率(recall)來進(jìn)行評判指標(biāo),本文使用{dev1,dev2,…}來表示推薦結(jié)果,使用{realresult}表示實(shí)際人工分配結(jié)果,精度是指推薦結(jié)果和實(shí)際人工分配結(jié)果的交集占推薦結(jié)果的比率,查全率是指推薦結(jié)果和實(shí)際人工分配結(jié)果的交集占實(shí)際人工分配結(jié)果的比率,如式(2)和式(3)所示。
(2)
(3)
實(shí)驗(yàn)的數(shù)據(jù)來源是Mozilla的缺陷報(bào)告庫,共有數(shù)據(jù)418 372條,全部是經(jīng)過整理后的格式規(guī)范的缺陷報(bào)告數(shù)據(jù)。實(shí)驗(yàn)數(shù)據(jù)只使用最終結(jié)果為“fixed”的數(shù)據(jù),為124 667條數(shù)據(jù),數(shù)據(jù)詳情如圖4所示。
圖4 實(shí)驗(yàn)數(shù)據(jù)描述
本文設(shè)計(jì)的實(shí)驗(yàn)需要去除低頻率的修復(fù)人,以提高實(shí)驗(yàn)的精度和查全率。本文設(shè)置frequency作為數(shù)據(jù)代替值。經(jīng)過參數(shù)的調(diào)整,將該值設(shè)置成為80。實(shí)驗(yàn)需要設(shè)定與新缺陷報(bào)告相似性最高的K個(gè)歷史缺陷報(bào)告,經(jīng)過反復(fù)實(shí)驗(yàn)和參數(shù)調(diào)整,將K設(shè)定為20。實(shí)驗(yàn)從原始數(shù)據(jù)中隨機(jī)提取出5組數(shù)據(jù),每組分為訓(xùn)練集和測試集。其中訓(xùn)練集和測試集保證優(yōu)先級和產(chǎn)品類別、組別相同。每組訓(xùn)練集數(shù)據(jù)為5 000條,測試數(shù)據(jù)100條。
3.2 實(shí)驗(yàn)結(jié)果
由于已經(jīng)將開發(fā)者的出現(xiàn)頻率和相似報(bào)告數(shù)量進(jìn)行預(yù)設(shè),實(shí)驗(yàn)的變量為要推薦的修復(fù)人的數(shù)量。通過修改推薦的數(shù)量(1~10個(gè)),各個(gè)指標(biāo)的顯示結(jié)果如圖5和圖6所示(圖中指標(biāo)為:frequency、closeness、betweenness、out-degree、in-degree、degree、pagerank)。
圖5 不同指標(biāo)的查準(zhǔn)率
圖6 不同指標(biāo)查全率
通過實(shí)驗(yàn)可以看到,最大的精度是frequency在只推薦一個(gè)修復(fù)人時(shí)達(dá)到,約為0.69。最大的查全率是frequency在推薦10個(gè)修復(fù)人時(shí)達(dá)到的,約為0.62。Closeness和Betweenness兩個(gè)指標(biāo)都不能得到良好的推薦效果,其查準(zhǔn)率都在0.3之下,查全率一直在0.4之下,推薦結(jié)果不能滿足實(shí)際需求。
總體來看,out-degree與frequency相比略遜一籌,但是訓(xùn)練集中的數(shù)據(jù)大概平均有5個(gè)修復(fù)人。由于Mozilla Firefox項(xiàng)目中有上千的修復(fù)人,所以out-degree也能夠作為推薦指標(biāo)之一。其他幾個(gè)指標(biāo),除了closeness和betweenness之外,都具有較好的缺陷修復(fù)人推薦性能,即保證推薦查準(zhǔn)率在65%以上。在實(shí)際應(yīng)用中,即使是人工分配,也會(huì)因?yàn)閭€(gè)人、環(huán)境和知識因素等而出現(xiàn)分配錯(cuò)誤,所以在允許誤差的范圍內(nèi),本文認(rèn)為OSDR的推薦修復(fù)人所達(dá)到的性能能夠應(yīng)用到實(shí)際項(xiàng)目中。
本文提出了OSDR方法來進(jìn)行缺陷修復(fù)人的自動(dòng)化推薦,該方法使用了缺陷報(bào)告的描述和開發(fā)者在開發(fā)缺陷庫中的評論。當(dāng)一個(gè)新的缺陷報(bào)告被提交的時(shí)候,該方法的運(yùn)行原理是首先得到與之相似度高的歷史缺陷報(bào)告,進(jìn)而采用多種指標(biāo)評價(jià)這些歷史缺陷報(bào)告對應(yīng)的開發(fā)者的專業(yè)能力,最后得到最匹配的缺陷修復(fù)人。實(shí)驗(yàn)表明,在應(yīng)用該方法來進(jìn)行缺陷修復(fù)人推薦時(shí),開發(fā)者在開放缺陷庫中出現(xiàn)的頻率和社交網(wǎng)絡(luò)圖中的出度是精度最高的評價(jià)指標(biāo)。但是,有一些因素會(huì)影響到該方法的準(zhǔn)確率,例如實(shí)驗(yàn)的數(shù)據(jù)集來自于MozillaFirefox社區(qū),這就需要該方法應(yīng)用的領(lǐng)域的數(shù)據(jù)的格式應(yīng)盡可能與之相同。然后就是評論中的一些言論可能并不能對問題的解決帶來幫助,這也將影響到社交網(wǎng)絡(luò)圖生成時(shí)候的精確度缺失。在未來的工作中,進(jìn)一步的研究將完善數(shù)據(jù)質(zhì)量和提升OSDR的泛化能力。
[1] Zhang W, Wang S, Wang Q. KSAP: An approach to bug report assignment using KNN search and heterogeneous proximity[J]. Information & Software Technology, 2015, 70:68-84.
[2] Park J W, Lee M W, Kim J, et al. CosTriage: A Cost-Aware Triage Algorithm for Bug Reporting Systems[C]// AAAI Conference on Artificial Intelligence, San Francisco, California, Usa, August. DBLP, 2011.
[3] Baysal O, Godfrey M W, Cohen R. A bug you like: A framework for automated assignment of bugs[C]// IEEE, International Conference on Program Comprehension. IEEE Xplore, 2009:297-298.
[4] Matter D, Kuhn A, Nierstrasz O. Assigning bug reports using a vocabulary-based expertise model of developers[C]// IEEE International Working Conference on Mining Software Repositories. IEEE, 2009:131-140.
[5] Anvik J. Automating bug report assignment[C]// International Conference on Software Engineering. DBLP, 2006:937-940.
[6] Tamrawi Ahmed, Tung Thanh Nguyen, Jafar Al-kofahi, et al. Fuzzy set and cache-based approach for bug triaging[J]. Dissertations & Theses Gradworks, 2011:365-375.
[7] Zhang T, Lee B. How to Recommend Appropriate Developers for Bug Fixing?[C]// Computer Software and Applications Conference (COMPSAC), 2012 36th Annual. IEEE, 2012:170-175.
[8] Zhang T, Lee B. A Hybrid Bug Triage Algorithm for Developer Recommendation[C]// The 28th ACM Symposium on Applied Computing. 2013:1088-1094.
[9] Xie X, Zhang W, Yang Y, et al. DRETOM: developer recommendation based on topic models for bug resolution[C]// ICPMSE 2012: International Conference on Predictive Models in Software Engineering 2012. ACM, 2012:19-28.
[10] Xia X, Loy D, Wang X, et al. Accurate developer recommendation for bug resolution[C]// Reverse Engineering (WCRE), 2013 20th Working Conference on. IEEE, 2013:72-81.
[11] Kanwal J, Maqbool O. Bug Prioritization to Facilitate Bug Report Triage[J]. Journal of Computer Science & Technology, 2012, 27(2):397-412.
[12] Xuan J, Jiang H, Ren Z, et al. Developer prioritization in bug repositories[C]// ICSE 2012: Software Engineering, 2012 34th International Conference on. IEEE, 2012.
[13] Servant F, Jones J. WhoseFault: automatic developer-to-fault assignment through fault localization[C]// ICSE 2012: Proceedings of the 34th International Conference on Software Engineering, 2012. IEEE Press, 2012:36-46.
[14] Zhang W, Tang X, Yoshida T. A comparative study of TF*IDF, LSI and multi-words for text classification[J]. Expert Systems with Applications, 2011, 38(3):2758-2765.
[15] 金弟, 劉杰, 賈正雪,等. 基于k最近鄰網(wǎng)絡(luò)的數(shù)據(jù)聚類算法[J]. 模式識別與人工智能, 2010, 23(4):546-551.
[16] Pohl M, Diehl S. What dynamic network metrics can tell us about developer roles[C]// International Workshop on Cooperative & Human Aspects of Software Engineering Acm. ACM, 2008:81-84.
[17] Ganev V, Guo Z, Serrano D, et al. Exploring and visualizing academic social networks[C]// CIKMP 2010: roceedings of the 19th ACM Conference on Information and Knowledge Management, October 26-30, 2010. Toronto, Ontario, Canada, 2010:1963-1964.
OSDR:ANOPENSOURCESOFTWAREDEFECTREPAIRDEVELOPERRECOMMENDEDMETHOD
Zhang Wen Li Ziqiang Du Yuhang Zhao Boyang
(CenterforBigDataSciences,BeijingUniversityofChemicalTechnology,Beijing100029,China)
For large open source software projects, users submit a large number of defect reports, manual distribution of defects will be a lot of misallocation. By calculating the similarity between the new defect report and the historical defect report,Khistorical defect reports with the highest similarity and the corresponding list of repair persons are obtained based on theKnearest neighbor algorithm, and then based on frequency and social network map of the indicators, the OSDR (Open Software Developer Recommendation) method proposed in this paper evaluates the developer’s professional competence. The real experiment data were collected from the Mozilla Firefox database to compare the accuracy and recall of different social network indicators when recommending the human. The results show that the recommended performance index is the frequency and out, and its accuracy is about 0.6 or so; Betweenness and Closeness recommended effect is the worst; Degrees, in-degree and PageRank recommended effect is good.
Open source software Defect Report Repair developer recommendation Social network analysis
2016-07-26。國家自然科學(xué)基金項(xiàng)目(61379046);中央高?;究蒲袠I(yè)務(wù)費(fèi)項(xiàng)目(buctrc201504)。張文,教授,主研領(lǐng)域:軟件工程,數(shù)據(jù)挖掘。李自強(qiáng),碩士生。杜宇航,碩士生。趙博揚(yáng),碩士生。
TP3
A
10.3969/j.issn.1000-386x.2017.08.002