軟件開發(fā)活動數(shù)據(jù)集的層次化、多版本化方法*

朱家鑫, 周明輝

1(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院 軟件研究所,北京 100871)

2(高可信軟件技術(shù)教育部重點實驗室(北京大學(xué)),北京 100871)

3(中國科學(xué)院 軟件研究所 軟件工程技術(shù)研究開發(fā)中心,北京 100190)

隨著軟件開發(fā)支撐技術(shù)的發(fā)展,相關(guān)工具在軟件開發(fā)生命期中的覆蓋度以及在軟件項目中的普及程度越來越高.版本控制系統(tǒng)、問題(issue)追蹤系統(tǒng)、郵件列表是在開發(fā)中最為常見的支撐工具.它們的數(shù)據(jù)庫中(軟件倉庫)記錄了軟件的新功能開發(fā)、缺陷修復(fù)、代碼審查等多種活動.隨著開源運動的不斷發(fā)展壯大,開放的軟件開發(fā)活動數(shù)據(jù)在不斷地累積并達到了非?？捎^的規(guī)模[1].通過分析這些數(shù)據(jù),人們可以獲取對開發(fā)活動更為準(zhǔn)確和深刻的認(rèn)識,進而有效地改進軟件開發(fā)實踐[2-4].

對軟件開發(fā)活動數(shù)據(jù)的分析通常需要人們投入大量的時間與精力收集、清洗與組織數(shù)據(jù)[5].在過去,大多數(shù)研究工作都是獨立地進行數(shù)據(jù)準(zhǔn)備工作,而這種方式非常低效:一方面,很多研究問題所需要的數(shù)據(jù)是相同的,因而整個研究社區(qū)中會出現(xiàn)大量重復(fù)性的工作;另一方面,基于不同數(shù)據(jù)集的分析結(jié)果在重現(xiàn)和對比時容易出現(xiàn)數(shù)據(jù)集缺失(例如分析者沒有公開所研究的數(shù)據(jù)集、數(shù)據(jù)集的鏈接失效等)、數(shù)據(jù)格式不統(tǒng)一、數(shù)據(jù)集差異引入混雜因素等問題.因此,很多工作嘗試著去構(gòu)建和共享公共的數(shù)據(jù)集來解決這些問題[5-9].

雖然有越來越多的研究者與實踐者關(guān)注了軟件開發(fā)活動數(shù)據(jù)的共享,但這些工作的關(guān)注點主要在于數(shù)據(jù)的公開和推廣,關(guān)于數(shù)據(jù)可用性[10-13]的考慮還存在較大不足.首先,現(xiàn)有的共享數(shù)據(jù)集有原始數(shù)據(jù)和定制數(shù)據(jù)這兩種形式.共享原始數(shù)據(jù)的做法減少了使用者在數(shù)據(jù)收集方面的成本,共享定制數(shù)據(jù)可以進一步減少數(shù)據(jù)預(yù)處理的成本.然而,大多數(shù)定制數(shù)據(jù)集的構(gòu)建過程可追溯性差,即數(shù)據(jù)收集與處理的過程不清晰,缺少中間結(jié)果,不利于數(shù)據(jù)質(zhì)量的驗證以及分析異常的排查,適用范圍也相對有限.其次,現(xiàn)有數(shù)據(jù)集往往是通過一次收集或者若干次增量收集而得到的,并沒有考慮到數(shù)據(jù)收集環(huán)境的變化以及軟件開發(fā)活動的變化,這些變化對數(shù)據(jù)可用性的影響也就無法得到揭示和處理.針對上述問題,本文提出一種層次化、多版本化的數(shù)據(jù)集構(gòu)建及使用方法.首先,該方法提出根據(jù)數(shù)據(jù)處理的不同程度劃分不同的數(shù)據(jù)層次,使數(shù)據(jù)集包含原始、中間和最終多個層次的數(shù)據(jù),從而建立數(shù)據(jù)集構(gòu)建過程的可追溯性,并兼顧應(yīng)用時的普適性;其次,該方法提出使用不同的方式在不同的時間段進行多次數(shù)據(jù)收集,形成數(shù)據(jù)集的多個版本,盡可能地將數(shù)據(jù)變化納入其中,為數(shù)據(jù)質(zhì)量及分析結(jié)果有效性的驗證和提高創(chuàng)造條件.基于我們構(gòu)建的 Mozilla問題追蹤數(shù)據(jù)集[14],本文展示了這種改進的數(shù)據(jù)集的構(gòu)建和使用方法,并驗證了其效果.

本文第 1節(jié)介紹軟件開發(fā)活動數(shù)據(jù)集的構(gòu)建與共享現(xiàn)狀,揭示其中的不足,并有針對性地提出層次化、多版本化的數(shù)據(jù)構(gòu)建與使用方法.第2節(jié)詳細(xì)闡述該方法.第3節(jié)給出一個具體的數(shù)據(jù)集構(gòu)建實例.第4節(jié)展示基于該實例的5個應(yīng)用示例.第5節(jié)對全文進行總結(jié).

1 軟件開發(fā)活動數(shù)據(jù)集的構(gòu)建與共享現(xiàn)狀

利用軟件開發(fā)支撐工具所記錄的數(shù)據(jù)來支持軟件開發(fā)實踐的改進是當(dāng)前軟件工程研究的一大趨勢[3].這種數(shù)據(jù)驅(qū)動的軟件開發(fā)活動分析主要包括了圖 1所示的一系列步驟.首先,從目標(biāo)項目所使用的開發(fā)支撐工具的數(shù)據(jù)庫,即軟件倉庫中收集原始數(shù)據(jù);其次,對這些原始數(shù)據(jù)進行清洗,去除無關(guān)數(shù)據(jù)、噪音數(shù)據(jù);接下來,對這些預(yù)處理后的數(shù)據(jù)進行適當(dāng)?shù)慕M織及存儲,方便后續(xù)的使用;在具體的研究中,分析者會根據(jù)研究問題建立相關(guān)的量度,從數(shù)據(jù)中得到度量結(jié)果并進行分析;最后一步是分析結(jié)果的驗證與應(yīng)用.可以看到,在進行分析之前,研究者要進行數(shù)據(jù)的收集、清洗、組織、存儲,而這部分工作的成本可能非常高昂,特別是面向大規(guī)模數(shù)據(jù)的時候[15].需要特別注意的是,這種成本包括了以下兩個方面:首先,數(shù)據(jù)的可得性由項目的數(shù)據(jù)開放政策決定,有些項目的數(shù)據(jù)需要與業(yè)務(wù)繁忙的項目管理者進行漫長的交涉,最終簽署協(xié)議才能獲得,即便是公開的數(shù)據(jù),由于要保障開發(fā)活動的正常進行,對開發(fā)支撐工具高頻率的數(shù)據(jù)獲取請求也是被禁止的,因此數(shù)據(jù)收集需要大量額外的時間開銷;其次,分析者個人的網(wǎng)絡(luò)條件也可能造成一些困難,例如網(wǎng)絡(luò)帶寬、網(wǎng)絡(luò)訪問的限制等,這些因素也會增大數(shù)據(jù)收集的復(fù)雜性.除了數(shù)據(jù)的收集,大量異構(gòu)原始數(shù)據(jù)的清洗、組織也需要較大的人力和數(shù)據(jù)存儲成本.因此,很多研究者提出通過數(shù)據(jù)共享來提高數(shù)據(jù)分析的效率:減少每一次分析的數(shù)據(jù)準(zhǔn)備成本,減少整個研究社區(qū)中的重復(fù)數(shù)據(jù)準(zhǔn)備工作,方便數(shù)據(jù)分析結(jié)果的重現(xiàn)與對比.

目前,研究社區(qū)中已經(jīng)有了相當(dāng)多構(gòu)建與共享數(shù)據(jù)集的工作,它們主要包括兩類:一類是構(gòu)建與發(fā)布特定的數(shù)據(jù)集,另一類是建設(shè)數(shù)據(jù)集共享的平臺.挖掘軟件倉庫的代表性會議 Int’l Conf. on Mining Software Repositories(MSR)[4]設(shè)有Data Showcase專區(qū),其中發(fā)表的大多數(shù)數(shù)據(jù)集是其作者在各自的研究中所構(gòu)建的.這些數(shù)據(jù)集中有的將軟件項目的開發(fā)歷史數(shù)據(jù)進行整合,例如Spinellis將UNIX系統(tǒng)44年的代碼演化歷史整合到一個Git倉庫中,通過Git命令人們可以查詢到過去UNIX代碼發(fā)生的改變[16];有的則對某些項目托管網(wǎng)站的數(shù)據(jù)進行大規(guī)模收集,為研究者提供數(shù)量眾多的軟件項目的多種開發(fā)活動數(shù)據(jù),包括版本控制數(shù)據(jù)、問題追蹤數(shù)據(jù)等,例如Gousios領(lǐng)導(dǎo)的收集、共享GitHub平臺上眾多開源項目開發(fā)數(shù)據(jù)的GHtorrent項目[17],還有一些是從軟件倉庫中提取與加工面向特定問題的數(shù)據(jù)集,例如Amann等人基于Sourceforge和GitHub上眾多版本控制庫構(gòu)建的用于測試 API誤用檢測器性能的標(biāo)桿數(shù)據(jù)集 MUBench[18].數(shù)據(jù)集共享平臺建設(shè)的典型項目有FLOSSmole[5]和 PROMISE[6],旨在為研究者們提供一個協(xié)作化的數(shù)據(jù)共享平臺,人們可以貢獻與獲取符合一定規(guī)范的各類軟件開發(fā)活動數(shù)據(jù),并分享自己基于這些數(shù)據(jù)所得到的研究成果.而MSR會議的Mining Challenge專區(qū)為研究者提供了一個數(shù)據(jù)分析競賽平臺,研究者基于一個公共的數(shù)據(jù)集來開展各種分析并一較高下.為了促進跨軟件倉庫挖掘的研究,Keivanloo等人又在平臺的建設(shè)上提出了將各類開發(fā)活動數(shù)據(jù)進行連接[19],他們設(shè)計了一種軟件開發(fā)活動數(shù)據(jù)模型,該模型中包含了一系列軟件開發(fā)所涉及到的對象,例如項目、代碼、缺陷、開發(fā)者、代碼提交等,從版本控制、問題追蹤等軟件倉庫中提取出這些對象并建立它們之間的關(guān)系,如開發(fā)者A執(zhí)行了代碼提交B,代碼提交B修復(fù)了缺陷C.基于該模型,開發(fā)者們搭建了SeCold平臺來共享有連接的軟件開發(fā)活動數(shù)據(jù)集.

上述工作的關(guān)注點主要在于促進數(shù)據(jù)的公開和傳播,而數(shù)據(jù)共享中的數(shù)據(jù)可用性問題還有待進一步研究.數(shù)據(jù)可用性被關(guān)注最多的方面是數(shù)據(jù)質(zhì)量[20],研究者們提出了數(shù)據(jù)的時效性、一致性、精確性、完整性、代表性等多個方面[21-26]的屬性來刻畫數(shù)據(jù)質(zhì)量.從應(yīng)用的角度來講,數(shù)據(jù)質(zhì)量決定了上層分析結(jié)果的有效性,例如在預(yù)測缺陷修復(fù)時間時,數(shù)據(jù)中標(biāo)定的缺陷修復(fù)完成時間的精確性非常關(guān)鍵,錯誤的時間記錄會使得預(yù)測模型無法得到有效的訓(xùn)練而給出錯誤的結(jié)果[27].再如,在訓(xùn)練缺陷預(yù)測模型時,訓(xùn)練數(shù)據(jù)中若包含非缺陷相關(guān)的噪音數(shù)據(jù),則模型的性能會出現(xiàn)一定的下降[28].數(shù)據(jù)可用性還有另一個關(guān)注較少的方面——數(shù)據(jù)的適用范圍,即一個數(shù)據(jù)集能夠幫助解決多少問題,例如基于某個項目的版本控制數(shù)據(jù)定制的一個關(guān)于缺陷修復(fù)活動的數(shù)據(jù)集可以用來度量該項目的缺陷密度、項目中開發(fā)者修復(fù)缺陷的經(jīng)驗等,但因為它只包含了缺陷修復(fù)的活動而無法用來度量版本控制數(shù)據(jù)中記錄的其他開發(fā)活動,如實現(xiàn)軟件的新功能.

之前的數(shù)據(jù)集構(gòu)建工作在數(shù)據(jù)可用性的保障上都或多或少地存在一些不足.這些不足主要表現(xiàn)為兩點:一是數(shù)據(jù)集缺乏構(gòu)建過程的可追溯性,即從原始數(shù)據(jù)到最終數(shù)據(jù)的整個數(shù)據(jù)處理過程沒有詳盡而準(zhǔn)確的描述,中間結(jié)果缺失;二是對數(shù)據(jù)收集與軟件開發(fā)活動的改變所引發(fā)的數(shù)據(jù)變化欠考慮.

可追溯性決定數(shù)據(jù)使用者能否處理分析中遇到的異常、驗證數(shù)據(jù)質(zhì)量、解決更多的軟件開發(fā)問題.有些數(shù)據(jù)共享工作提供所收集的原始數(shù)據(jù),例如MSR07的Mining Challenge專區(qū)提供的問題追蹤數(shù)據(jù)集[29],而更多的工作則提供經(jīng)過清洗、轉(zhuǎn)換等處理后定制化的數(shù)據(jù),例如 Habayeb等人的 Firefox Temporal Defect Dataset(FTDD)[30],Gousios等人的GHtorrent MySQL database dump數(shù)據(jù)集[17].相對于原始數(shù)據(jù),分享定制化的數(shù)據(jù)可以降低數(shù)據(jù)預(yù)處理的成本,然而,這些數(shù)據(jù)集大都以黑盒式的方式提供,原始數(shù)據(jù)以及中間的處理過程、中間數(shù)據(jù)都較為模糊或者完全缺失,可追溯性較差,由于缺少中間的過程及數(shù)據(jù),數(shù)據(jù)質(zhì)量驗證以及分析異常的處理,這些需要追溯數(shù)據(jù)處理過程的工作難以開展,定制過程中被移除的開發(fā)活動信息也無法得到恢復(fù),能夠用以解決的軟件開發(fā)問題只能是特定的.

對數(shù)據(jù)變化的考慮程度決定了數(shù)據(jù)分析的結(jié)果是否有效以及在什么樣的條件下有效.當(dāng)前大多數(shù)數(shù)據(jù)共享工作并沒有對可能的數(shù)據(jù)變化予以考慮,共享的數(shù)據(jù)集大都是一次收集或者若干次增量式收集所得到的,由于缺少參照,數(shù)據(jù)收集環(huán)境的變化以及軟件開發(fā)活動的變化無法被揭示,其中,數(shù)據(jù)收集環(huán)境的變化可能引起數(shù)據(jù)質(zhì)量的改變,例如訪問受限、網(wǎng)絡(luò)連接中斷、腳本缺陷等會導(dǎo)致數(shù)據(jù)的缺失和出錯,軟件開發(fā)活動的變化可能導(dǎo)致原有數(shù)據(jù)分析結(jié)果不再有效,如Ioannidis指出很多已有數(shù)據(jù)分析結(jié)果在新的數(shù)據(jù)集上無法得到重現(xiàn)[31].

為幫助解決上述問題,本文提出一種改進的數(shù)據(jù)構(gòu)建及使用方法,通過層次化使數(shù)據(jù)集的構(gòu)建過程可追溯,使數(shù)據(jù)集的適用范圍可伸縮,通過多版本化來捕獲數(shù)據(jù)的動態(tài)變化.在下一節(jié)中我們分別對這兩種設(shè)計進行詳細(xì)的介紹.

2 數(shù)據(jù)集的層次化與版本化

2.1 數(shù)據(jù)集的層次化

本文所提出的“層次化”概念中的“層次”指的是依據(jù)對數(shù)據(jù)進行預(yù)處理的程度而劃分的不同數(shù)據(jù)層次.考慮多個數(shù)據(jù)層次既可以降低數(shù)據(jù)收集與預(yù)處理的成本,又可以通過保留全部業(yè)務(wù)信息來兼顧數(shù)據(jù)的適用范圍,與此同時,數(shù)據(jù)集構(gòu)建過程的追溯性也得到了建立,保障了數(shù)據(jù)質(zhì)量與數(shù)據(jù)分析結(jié)果的有效性.

如圖2所示,層次化的數(shù)據(jù)集包含兩個基本的層次:原始數(shù)據(jù)層(層次0)和標(biāo)準(zhǔn)化數(shù)據(jù)層(層次1).層次0中的數(shù)據(jù)是從開發(fā)支撐工具中所收集到的未經(jīng)其他處理的數(shù)據(jù),這些數(shù)據(jù)保留了數(shù)據(jù)共享者在數(shù)據(jù)收集時能夠獲取的全部開發(fā)活動信息,并且不包含數(shù)據(jù)預(yù)處理所可能引入的偏倚.但是,層次 0中數(shù)據(jù)的數(shù)據(jù)模式由支撐工具所定義,在使用前需要進行特定的解析來獲取相關(guān)的信息,例如從版本控制系統(tǒng)的庫中獲取提交信息需要使用系統(tǒng)提供的接口(命令行或圖形化用戶接口、編程接口)來進行查詢,從問題追蹤系統(tǒng)中獲取問題追蹤信息需要對 Web頁面進行解析.此外,原始數(shù)據(jù)中可能包含大量的與開發(fā)活動無關(guān)的數(shù)據(jù)及冗余數(shù)據(jù)(如Web頁面中用來布局和美化頁面的標(biāo)簽等),增加不必要的數(shù)據(jù)傳播和存儲開銷.因此,對原始數(shù)據(jù)進行數(shù)據(jù)提取和標(biāo)準(zhǔn)化十分必要.本文設(shè)計了層次 1來加入標(biāo)準(zhǔn)化數(shù)據(jù).標(biāo)準(zhǔn)化數(shù)據(jù)包含了從原始數(shù)據(jù)中提取出的全部開發(fā)活動相關(guān)數(shù)據(jù),并且以方便后續(xù)使用的數(shù)據(jù)格式來組織,例如解析簡便、以純文本方式存儲的 CSV(comma-separated values)格式[32].在層次 1之上,數(shù)據(jù)共享者還可以增加面向特定研究問題的層次2+的數(shù)據(jù).這些較高層次中的數(shù)據(jù)經(jīng)由對層次1中數(shù)據(jù)的進一步處理而得到.這些處理與研究問題相關(guān),可以是特定開發(fā)活動信息的提取、數(shù)據(jù)的拼接、數(shù)據(jù)的轉(zhuǎn)換等,例如從郵件列表的數(shù)據(jù)中只提取出那些關(guān)于代碼審查的會話,構(gòu)建代碼審查數(shù)據(jù)集[33];將一個缺陷的報告與解決該缺陷的代碼提交進行連接[34];將問題報告的解決活動進行抽象、編碼[30].

使用層次化數(shù)據(jù)集的第 1步是選取適當(dāng)層次的數(shù)據(jù).一般而言,當(dāng)確定要使用某個軟件開發(fā)支撐工具所記錄的數(shù)據(jù)時,任何分析都可以使用相應(yīng)數(shù)據(jù)集中層次 1的數(shù)據(jù).這是因為層次 1的數(shù)據(jù)包含了目標(biāo)工具中記錄的全部開發(fā)活動信息,能夠滿足不同問題的數(shù)據(jù)需求.雖然使用層次 0的數(shù)據(jù)也可以達到同樣的目的,但使用層次 1的數(shù)據(jù)既可以減小數(shù)據(jù)下載及存儲的代價,又不需要進行數(shù)據(jù)的提取及標(biāo)準(zhǔn)化.如果要重現(xiàn)某項研究的結(jié)果,或者是進行相似問題的研究,那么可以考慮直接使用更高層次的數(shù)據(jù),省去相關(guān)的數(shù)據(jù)提取、拼接甚至度量的工作.例如,如果要研究問題報告(issue report)解決過程中的活動模式,則可以直接使用Habayeb等人所構(gòu)建的FTDD數(shù)據(jù)集[30]而不是MSR07 Mining Challenge的數(shù)據(jù)集[29],該數(shù)據(jù)集已對原始的問題追蹤數(shù)據(jù)進行了數(shù)據(jù)標(biāo)準(zhǔn)化之外的深層處理,其中的數(shù)據(jù)相當(dāng)于本文介紹的層次2或?qū)哟?+中的數(shù)據(jù).利用這樣的數(shù)據(jù)集可以免去對問題處理活動與問題報告屬性之間的拼接(在原始數(shù)據(jù)中這兩類數(shù)據(jù)是分別保存的)、對問題處理活動的編碼等.但是,該數(shù)據(jù)集并不是層次化的,其所包含的問題追蹤信息可能無法滿足其他研究的需求.例如,該數(shù)據(jù)集在對活動編碼時過濾了問題報告狀態(tài)的變遷信息,對于需要考慮該信息的研究,FTDD顯然是不適用的.這個時候就需要回到層次1,基于層次1中的數(shù)據(jù)重新構(gòu)建更高層次的數(shù)據(jù).

層次化數(shù)據(jù)集的可追溯性對于提高數(shù)據(jù)分析結(jié)果的有效性非常有幫助.在使用高層次的數(shù)據(jù)進行分析時,數(shù)據(jù)使用者如果遇到異常,可以回退到較低層次來排查異常產(chǎn)生的原因.這些異?？赡軄碜杂谲浖_發(fā)活動本身,也可能來自數(shù)據(jù)收集以及后續(xù)處理的過程.隨著數(shù)據(jù)層次的提高,原始數(shù)據(jù)被處理的程度在不斷加深,其間出現(xiàn)差錯的概率也會隨之增大.利用層次化的數(shù)據(jù)集,使用者可以以逐層回退的方式查找異常的源頭.如果異常僅出現(xiàn)在某個層次以上的數(shù)據(jù)層中,那么它是由相關(guān)數(shù)據(jù)收集或處理腳本的缺陷所引起的.此時,要對錯誤進行修正并重新構(gòu)建有問題的數(shù)據(jù)層.如果支撐工具的數(shù)據(jù)庫中也存在該異常,那么它很可能由軟件開發(fā)活動中的某些特殊情況所引發(fā).此時,要對該異常作進一步的探查及解釋,并在數(shù)據(jù)處理中根據(jù)具體情況對異常數(shù)據(jù)進行分離、過濾或者保留.

2.2 數(shù)據(jù)集的多版本化

本文提出的“多版本”概念中的“版本”指的是通過不同的方式或是在不同的時間所收集到的各個數(shù)據(jù)快照.包含多個版本的數(shù)據(jù)可以將數(shù)據(jù)收集及軟件開發(fā)中發(fā)生的各種變化納入到數(shù)據(jù)集中,為提高數(shù)據(jù)的質(zhì)量及分析結(jié)果有效性建立基礎(chǔ).

如圖 3所示,多版本的數(shù)據(jù)要以多種方式在多個時間段以不同的方式進行數(shù)據(jù)收集.數(shù)據(jù)的收集一般有兩類方式:一類是通過開發(fā)支撐工具的交互接口間接地獲取數(shù)據(jù),另一類是直接導(dǎo)出開發(fā)支撐工具后臺數(shù)據(jù)庫中的數(shù)據(jù).對于前者,工具的交互接口又可以分為圖形化的或命令行的人機交互界面,以及應(yīng)用程序編程接口(API),例如GitHub API[7];對于后者,數(shù)據(jù)庫的類型可能是普通的關(guān)系型數(shù)據(jù)庫,如Bugzilla的MySQL關(guān)系型數(shù)據(jù)庫,也可能是工具自定義的數(shù)據(jù)庫,如 Git基于對象的有向無環(huán)圖數(shù)據(jù)庫.在這些收集方式中進行切換、對比可以揭示不同方式對原始數(shù)據(jù)所產(chǎn)生的影響,進而建立評估每種方式所得數(shù)據(jù)的質(zhì)量的基礎(chǔ).間隔一定的時間,例如 1年,進行多次數(shù)據(jù)收集則可以納入我們在第 1節(jié)中提到的數(shù)據(jù)變化,這些變化可以分為兩類:一類是數(shù)據(jù)收集環(huán)境的變化,另一類是軟件開發(fā)活動的變化.數(shù)據(jù)收集環(huán)境的變化可能導(dǎo)致數(shù)據(jù)收集過程中異常情況的發(fā)生,例如數(shù)據(jù)源訪問受限導(dǎo)致部分信息無法獲取.這些異常情況將使收集到的數(shù)據(jù)發(fā)生殘缺或錯誤.開發(fā)活動的變化會改變相應(yīng)的數(shù)據(jù),可能使其具有不同的特點和性質(zhì).

在進行數(shù)據(jù)分析時,數(shù)據(jù)使用者需要充分考慮上述數(shù)據(jù)收集方式的不同及數(shù)據(jù)本身的變化,分析它們是否反映了數(shù)據(jù)質(zhì)量問題,對數(shù)據(jù)分析結(jié)果的有效性存在怎樣的影響.使用多版本數(shù)據(jù)的核心思想是對不同版本數(shù)據(jù)進行交叉對比,實現(xiàn)數(shù)據(jù)質(zhì)量的驗證、開發(fā)活動變化的分析、數(shù)據(jù)分析有效性的評估和提高.

數(shù)據(jù)質(zhì)量的驗證在單一版本的數(shù)據(jù)集上相對困難,數(shù)據(jù)使用者需要對軟件開發(fā)活動本身有深入的理解、擁有分析相關(guān)數(shù)據(jù)的豐富經(jīng)驗[2]才能發(fā)現(xiàn)其中存在的質(zhì)量問題.而利用多版本進行對比則容易得多.具體來說,數(shù)據(jù)使用者首先找出版本間的不同,然后探究這些不同是否反映了數(shù)據(jù)質(zhì)量問題.例如在第4.2.2節(jié)中提到的不完整的用戶郵件地址顯然屬于數(shù)據(jù)質(zhì)量問題.該問題可以利用多版本中的冗余數(shù)據(jù)(其他版本中完整的地址)進行修復(fù).

軟件的開發(fā)活動在不斷推進演化,多版本間的不同也包含了開發(fā)活動變化.我們可以借助該特點拓展研究問題的范圍,探究新的有價值的問題.例如,探索識別敏感問題報告的技術(shù)、解決敏感問題報告的最佳實踐.

當(dāng)在單一的數(shù)據(jù)集上進行數(shù)據(jù)分析時,分析者對分析結(jié)果的有效性缺乏足夠的認(rèn)識,無法對分析過程及分析模型進行改進.而多版本的數(shù)據(jù)集中納入了多種實際發(fā)生的開發(fā)活動的變化.該特點可以幫助評估和提高數(shù)據(jù)分析有效性.例如,在開源項目長期貢獻者形成的研究[35]中,我們使用了 3個版本(這里簡稱版本 A、B和 C)的Mozilla問題追蹤數(shù)據(jù).版本A與B是通過爬取Bugzilla的Web頁面所得到的,版本C是后來取得的官方的Bugzilla數(shù)據(jù)庫dump.借助于這3個版本的數(shù)據(jù)集,我們對研究結(jié)果的有效性進行了兩項驗證,在第1項驗證中,我們使用版本A擬合(訓(xùn)練)模型,使用版本B測試模型;在第2項驗證中,我們使用版本C重現(xiàn)前面得到的模型.通過這種方式,我們在更大程度上保障了研究結(jié)果的有效性.

3 數(shù)據(jù)集構(gòu)建示例

根據(jù)上一節(jié)提出的方法,我們構(gòu)建并發(fā)布了一個Mozilla問題追蹤數(shù)據(jù)集(該數(shù)據(jù)集已發(fā)表于MSR 2016的Data Showcase Track[9].本文系統(tǒng)化地闡述了構(gòu)建此類數(shù)據(jù)集的方法論,并基于該數(shù)據(jù)集做了多項具體應(yīng)用),其訪問地址為https://github.com/jxshin/mzdata.Mozilla是一個具有20多年歷史的大型開源軟件項目,它旗下有我們耳熟能詳?shù)腇irefox瀏覽器、Thunderbird郵件客戶端等產(chǎn)品.該項目使用了Bugzilla問題追蹤系統(tǒng)[36]來管理各類開發(fā)問題,例如軟件缺陷、新功能請求(它們被總稱為“問題”)的報告及解決.在Bugzilla中,問題報告的報告時間、報告者、處理進度、處理結(jié)果等信息被跟蹤記錄,關(guān)于這些信息的細(xì)節(jié),第 3.1節(jié)有詳細(xì)的介紹.目前,已有非常多軟件工程的研究使用了問題追蹤數(shù)據(jù),所研究的問題包括缺陷的預(yù)測[37]、定位[38]、分類[39]和修復(fù)[40],開源代碼的貢獻的機制[41]等,其所具有的價值可見一斑.因此,我們利用上一節(jié)提出的方法構(gòu)建具有更高可用性的Mozilla問題追蹤數(shù)據(jù)集來支撐相關(guān)研究.下面兩個小節(jié)分別從層次化和多版本化兩個方面詳細(xì)介紹了該數(shù)據(jù)集.

3.1 層次化的Mozilla問題追蹤數(shù)據(jù)集

該數(shù)據(jù)集包含了層次0和層次1兩個基本數(shù)據(jù)層.其中,層次 0是從 Bugzilla所獲取的原始數(shù)據(jù),對于不同版本的數(shù)據(jù)(詳見第 3.2節(jié)),原始數(shù)據(jù)的形式會有所區(qū)別,在某些版本中,層次 0的數(shù)據(jù)是通過Bugzilla的用戶 Web界面所獲取的 Web頁面,而在其他的版本中,這些原始數(shù)據(jù)是從Bugzilla后臺數(shù)據(jù)庫中導(dǎo)出的脫敏dump.如圖4所示,這兩種形式的原始數(shù)據(jù)包含了相同類型的信息,包括每個問題報告的報告者、報告時間、嚴(yán)重程度、狀態(tài)等屬性,某些屬性(如問題狀態(tài))的變更歷史以及關(guān)于該問題報告的評論、評論者.在 Bugzilla的 Web界面中,這些信息由兩類頁面所記錄,一類是關(guān)于問題報告基本信息的頁面(HTML或XML格式),包括問題報告的當(dāng)前屬性和相關(guān)評論,另一類是部分問題報告屬性變更記錄的頁面(HTML格式);而在 Bugzilla的后臺數(shù)據(jù)庫中,每一類問題追蹤信息記錄于相應(yīng)的數(shù)據(jù)表中.關(guān)于這些原始數(shù)據(jù)的數(shù)據(jù)模式,XML及HTML文件中的標(biāo)簽的name說明了每個域的含義,而數(shù)據(jù)庫中有一張叫作fielddef的表,表中包含了各個域的含義.

從Web界面獲得的層次0數(shù)據(jù)除了包含開發(fā)中人們報告和解決問題的活動記錄,還包含了大量的HTML及XML標(biāo)簽,這些標(biāo)記使得數(shù)據(jù)產(chǎn)生較大的膨脹,不利于數(shù)據(jù)的傳播及存儲.此外,為了從Web頁面中分離出問題追蹤的業(yè)務(wù)數(shù)據(jù),還需要對這些頁面進行解析.因此,我們進一步構(gòu)建了層次 1的標(biāo)準(zhǔn)化數(shù)據(jù),將層次 0中的XML、HTML頁面、數(shù)據(jù)庫dump標(biāo)準(zhǔn)化.這種標(biāo)準(zhǔn)化處理僅僅是數(shù)據(jù)格式的轉(zhuǎn)換,所有層次 0中的問題追蹤信息都得到了保留,但層次1數(shù)據(jù)的體量有了大幅度的減小.層次1的數(shù)據(jù)采用了CSV格式,數(shù)據(jù)的解析與提取相比于原始的Web頁面要容易得多.該層數(shù)據(jù)分為問題報告基本信息與問題報告處理活動歷史兩部分,圖5描述了基本信息(a)與活動歷史(b)的數(shù)據(jù)模式,每一項基本信息由record_id唯一標(biāo)識,每一條評論域的命名方式為“l(fā)ong:〈評論 id(此條記錄內(nèi))〉:〈評論屬性名〉”,每一個問題屬性域由對應(yīng)的屬性命名,“=”后接各個域的值;每一項活動歷史同樣由record_id唯一標(biāo)識,每個域的命名方式為“〈活動id〉:x”,其中,x編碼了活動的屬性,0為活動執(zhí)行者,1為執(zhí)行時間,2為被修改的問題屬性,3為屬性原值,4為屬性新值,Bug表示對應(yīng)問題報告的id,“=”后接各個域的值.

在層次 1之上,數(shù)據(jù)使用者可以對數(shù)據(jù)進行提取、組合、計算等處理,構(gòu)建面向某些特定研究問題的定制化問題追蹤數(shù)據(jù),例如第4.2.1節(jié)中所介紹的示例.

3.2 多版本化的Mozilla問題追蹤數(shù)據(jù)集

目前,我們的Mozilla問題追蹤數(shù)據(jù)集共有4個版本,每個版本最直觀的區(qū)別體現(xiàn)在原始數(shù)據(jù)獲取的時間及方式的不同上.首先,這4個版本的原始數(shù)據(jù)分別收集于2011年、2012年、2013年和2016年,為了方便闡述,我們以這4個年份來命名這4個版本的數(shù)據(jù);其次,這4次數(shù)據(jù)收集使用了兩種不同的方法:一種是目前研究社區(qū)中最常使用的基于爬蟲的方法,我們批量地下載Bugzilla的用戶Web頁面;而另一種方法則與眾不同,我們通過積極地與Mozilla社區(qū)溝通,獲得了的經(jīng)過脫敏處理的Bugzilla后臺數(shù)據(jù)庫dump.我們使用前者收集了2011年與2012年的數(shù)據(jù),而通過后者收集了后兩個版本的數(shù)據(jù).相對于Web頁面,數(shù)據(jù)庫dump的下載要容易很多,它既不會干擾社區(qū)的正常工作,也不會受到訪問頻率及下載速度的限制以及爬蟲自身 bug的影響.表 1是這 4個版本數(shù)據(jù)的概況,從中我們可以看到,它們在問題報告數(shù)量、參與者人數(shù)等各個方面都存在明顯的不同.

Table 1 Summary of the Mozilla issue tracking dataset表1 Mozilla問題追蹤數(shù)據(jù)集的概況

我們進一步對比和總結(jié)了各個版本間的差異.首先,本文在第 3.1節(jié)已經(jīng)闡述過,不同的數(shù)據(jù)收集方式獲得的原始數(shù)據(jù)模式不同.其次,爬取的數(shù)據(jù)由于經(jīng)歷了較長的數(shù)據(jù)下載過程,一致性較弱.例如,一小部分問題報告的屬性值與其最后一次變更的值不匹配,這是因為第 3.1節(jié)提到了兩類 Web頁面是分開收集的,存在一定的時間差,這期間可能發(fā)生相關(guān)屬性的修改活動.最后,新版本的數(shù)據(jù)還包含了一些新的變化,主要包括以下5類.

(1) 新增加與減少的問題報告.新增問題報告主要是隨時間推移而新提交的報告,此外,還包括了過去未被公開的敏感報告.減少的問題報告主要包括因具有敏感性而被隱藏的報告.

(2) 新增的問題報告屬性值.隨著開發(fā)的演進,某些問題報告屬性的值域會產(chǎn)生一定變化,例如某個問題所屬的軟件版本,在較新版本的數(shù)據(jù)集中,該屬性的取值范圍會增加后續(xù)編排的新版本號.

(3) 新增的開發(fā)活動參與者.開發(fā)社區(qū)中不斷地有新的人員參與進來,如新的問題報告者、開發(fā)者、評論者等,他們的活動記錄會出現(xiàn)在較新版本的數(shù)據(jù)集中.

(4) 新增的問題處理活動.在一次數(shù)據(jù)收集中,會有相當(dāng)一部分問題報告還處于處理過程中,因此,在新收集到的數(shù)據(jù)中會增加這些問題報告的后續(xù)處理記錄.

(5) 問題報告屬性值的變化.根據(jù)變化的原因我們將其歸為 4種類型:① 由問題的后續(xù)處理活動所引起的,例如,問題被分配到新的開發(fā)者,問題的處理狀態(tài)更新;② 由開發(fā)者對自己賬戶修改所引發(fā)的,如用戶郵件地址的變更;③ 由于收集過程異常而導(dǎo)致的,如因爬蟲丟失登錄狀態(tài)而導(dǎo)致的用戶郵件地址后綴的缺失;④ 不同數(shù)據(jù)收集方式下原始數(shù)據(jù)格式不同造成的,例如Web頁面中的時間戳有時區(qū)信息而數(shù)據(jù)庫中的時間戳缺少該信息.

4 數(shù)據(jù)集應(yīng)用示例

我們通過層次化使數(shù)據(jù)集具備了可追溯、可擴展性,通過多版本化在數(shù)據(jù)集中納入了數(shù)據(jù)的變化,我們期望數(shù)據(jù)使用者可以利用這些特性來提高數(shù)據(jù)質(zhì)量、提高數(shù)據(jù)分析結(jié)果的有效性、拓展研究范圍等.本節(jié)以上一節(jié)中介紹的Mozilla問題追蹤數(shù)據(jù)集為例,從對數(shù)據(jù)變化性的挖掘及對數(shù)據(jù)集構(gòu)建過程的追溯兩個方面來展示5個應(yīng)用,示范層次化、多版本化數(shù)據(jù)集的使用,驗證本文方法的有效性.

4.1 數(shù)據(jù)變化性的發(fā)掘與應(yīng)用

軟件開發(fā)活動會使相應(yīng)的數(shù)據(jù)產(chǎn)生多種變化,某些變化可能會給數(shù)據(jù)使用者的分析造成一定的困難,例如同一個開發(fā)者在不同階段使用不同的身份標(biāo)識,造成開發(fā)者識別的困難;而某些變化則會給人們帶來探索新問題的機遇,例如新數(shù)據(jù)集中所包含的在過去敏感的數(shù)據(jù)為敏感問題的研究提供了機會.將數(shù)據(jù)多版本化之后,我們可以通過對比某些對象及其屬性在不同的版本間的變化來檢查和修復(fù)數(shù)據(jù)的不一致,驗證分析模型的有效性或者研究新的軟件開發(fā)問題.

第3.2節(jié)總結(jié)了示例數(shù)據(jù)集新舊版本間的變化情況,下面就其中的3項具體變化:Bugzilla用戶賬戶的改變、活動時間戳的改變以及新增問題報告與活動數(shù)據(jù),我們做了示范性的3個應(yīng)用.

4.1.1 Bugzilla用戶賬戶的改變

Bugzilla用戶,即軟件開發(fā)活動的參與者在使用該系統(tǒng)時需要創(chuàng)建自己的賬戶,該賬戶以用戶所填寫的郵件地址作為用戶標(biāo)識.因此,數(shù)據(jù)分析者通常利用郵件地址來對不同的用戶進行識別,然而這種方法存在一定的局限性.圖6展示了用戶與賬戶、賬戶與郵件地址之間的對應(yīng)關(guān)系.其中,一個用戶可以注冊多個Bugzilla的賬戶,而一個賬戶在使用過程中也可能更換郵件地址.因此,直接以郵件地址來識別用戶可能會把一個實際的用戶當(dāng)作多個.目前,已有研究者嘗試提出識別這些“別名”的方法[42,43].然而,“別名”的識別仍然存在很多的困難尚待解決,尤其是問題追蹤數(shù)據(jù)中的“別名”識別,其中最主要的是缺乏檢驗這些方法是否有效的測試數(shù)據(jù)(特別地,基于有監(jiān)督學(xué)習(xí)的方法缺乏必要的訓(xùn)練數(shù)據(jù)).因此,我們嘗試在多個版本的Mozilla數(shù)據(jù)間進行比對,探究是否可以發(fā)現(xiàn)“別名”實例,是否可以進一步利用多版本的手段更完全地抽取出開發(fā)者們所使用的“別名”,建立“別名”的數(shù)據(jù)集.

Table 2 Usage of multiple e-mail address and accounts表2 用戶使用多郵件地址、多賬戶的情況

Bugzilla中每個問題的報告者是某一個特定的開發(fā)者,不會發(fā)生改變,這是客觀事實.對于某個問題,如果系統(tǒng)中記錄的報告者的郵件地址在不同版本的數(shù)據(jù)集中不同,那么這些不同的郵件地址一定都屬于該報告者,他們代表同一個人.根據(jù)該原理,我們將 4個版本的數(shù)據(jù)集中的同一個問題的報告者的郵件地址提取出來進行對比、聚集.具體地,我們首先將關(guān)聯(lián)到同一個問題的郵件地址收集到同一個集合中,然后通過非大小寫敏感的字符串完全匹配將這些集合中包含相同地址的集合合并,最終得到使用過多個郵件地址用戶以及他們使用過的郵件地址.此外,在一個版本的數(shù)據(jù)集中,作為一個賬戶的標(biāo)識的郵件地址一定是唯一的,如果一個用戶的多個郵件地址出現(xiàn)在了一個版本的數(shù)據(jù)集中,說明該用戶使用了多個賬戶.我們利用得到的每一個用戶的郵件地址集合,在每一個版本的數(shù)據(jù)集中進行郵件地址的完全匹配查找,結(jié)果發(fā)現(xiàn),確實存在一個用戶使用多個賬戶的實例.表2是對用戶使用多個賬戶、多個郵件地址的情況的總結(jié).從中可以看到,大約有2 046個(1949+88+9,約1%)用戶使用過兩個及以上郵件地址,所涉及的郵件地址有 4 198個.使用多個賬戶的用戶則要少很多,我們只發(fā)現(xiàn)了35個,占比不到萬分之二.

我們利用4個版本的數(shù)據(jù)集挖掘出了4 000多個“別名”郵件地址.排除外部的客觀因素,例如Bugzilla系統(tǒng)的bug可能引入的錯誤數(shù)據(jù),該方法所識別的多郵件地址、多賬戶一定都是真正例(true-positive),達到了本示例的目的.至于識別的完整性,該方法無法保證.如果擁有更多的版本,我們可以得到更為完全的結(jié)果.當(dāng)擁有這樣的“別名”數(shù)據(jù)集后,研究者便可判斷“別名”對所要分析的問題所造成的威脅大小,對“別名”進行去重,甚至可以對用戶使用“別名”的習(xí)慣進行挖掘,尋找相關(guān)的模式.

4.1.2 活動時間戳的改變

在全球開發(fā)背景下,數(shù)據(jù)分析者要特別注意開發(fā)活動時間戳的時區(qū),如果時區(qū)信息被忽略,那么計算中的某個活動的時間誤差可能會高達24小時(地理位置最多可差24個時區(qū)),這種誤差會對某些較為精細(xì)的時間度量造成較大的威脅,例如開發(fā)者在一天當(dāng)中的工作時段及在不同時段中工作的效率.在從Bugzilla的Web界面獲取的原始數(shù)據(jù)中我們可以看到,所有的時間戳都標(biāo)注了時區(qū)(如圖7(a)所示),而在Bugzilla的數(shù)據(jù)庫dump中,時區(qū)信息是缺失的(如圖 7(b)所示),那么我們能希望知道在 Bugzilla數(shù)據(jù)庫 dump中的時間是否是以統(tǒng)一的時區(qū)來進行記錄的.

如果只有Bugzilla數(shù)據(jù)庫的dump,我們很難去回答這個問題.但當(dāng)我們擁有了從Web界面獲取的數(shù)據(jù),就可以對比同一個事件,例如一個問題報告的提交在兩個不同版本數(shù)據(jù)集中的時間.我們對比了通過所有報告在Web界面獲得的數(shù)據(jù)中記錄的提交時間和數(shù)據(jù)庫dump中記錄的提交時間,結(jié)果發(fā)現(xiàn),數(shù)據(jù)庫dump中的時間戳比Web界面中的時間戳少了時區(qū),其他數(shù)字一致.這說明,數(shù)據(jù)庫dump中所記錄的活動時間是不準(zhǔn)確的.為了探查這種偏差的程度以及是否有可能修復(fù),我們進一步分析了Web界面中時間戳的時區(qū),結(jié)果發(fā)現(xiàn),只涉及到了兩個時區(qū),分別是太平洋標(biāo)準(zhǔn)時間(PST-0800)和太平洋夏季時間(PDT-0700).其中,太平洋夏季時間在美國的夏季使用:在2006年以及之前,PDT始于每年4月第1個星期日深夜二時正,并終于10月的最后一個星期日深夜二時正.在2007年及以后,PDT始于每年3月的第2個星期六深夜二時正,并終于每年11月的第1個星期日深夜二時正.我們對Web界面獲取的數(shù)據(jù)集進行了分析,查看了PST與PDT在月份上的分布,結(jié)果符合上述規(guī)則.因此,我們可以利用該規(guī)則對數(shù)據(jù)庫 dump中的時間進行修正,填補相應(yīng)的時區(qū)信息,例如在數(shù)據(jù)庫 dump中,第665317號問題的報告時間是2011-06-18 13:35:00,它發(fā)生于2007年之后,具體時間在6月,處于3月的第2個星期六深夜二時和 11月的第 1個星期日深夜二時之間,填補時區(qū) PDT.再如第 619558號問題的報告時間為2010-12-15 16:22:00,在上述范圍之外,填補時區(qū)PST.

4.1.3 新增問題報告與活動數(shù)據(jù)

在挖掘問題追蹤數(shù)據(jù)工作中,有很多都是構(gòu)造某種分類模型,幫助提高問題處理的效率.例如,對問題報告是否為重復(fù)報告(與某個正在處理的報告反映的是相同的問題)進行識別的模型.這些模型需要訓(xùn)練數(shù)據(jù)來構(gòu)造,也需要測試數(shù)據(jù)來評估模型的性能并對其進行調(diào)整.獲取這兩類數(shù)據(jù)的通常的做法是將一個完整的數(shù)據(jù)集分成兩個部分:一部分作為訓(xùn)練數(shù)據(jù),另一部分作為測試數(shù)據(jù).這樣的測試數(shù)據(jù)是否能有效地代表實際應(yīng)用中的輸入數(shù)據(jù)決定了模型的可用性,是一個值得關(guān)注的問題.當(dāng)我們擁有了兩個在不同時間段所收集的數(shù)據(jù)集時,便可以構(gòu)造出3類數(shù)據(jù):實驗中的訓(xùn)練數(shù)據(jù)、測試數(shù)據(jù)(較早版本中的數(shù)據(jù))、實際應(yīng)用中的數(shù)據(jù)(較新版本中的數(shù)據(jù))來回答該問題.下面,我們就以2013年與2016兩個版本的Mozilla數(shù)據(jù)以及識別重復(fù)問題報告的分類器為例進行研究.

首先,我們構(gòu)造一個簡單的識別重復(fù)問題報告的分類器:該模型基于邏輯斯蒂回歸,使用問題報告提交者的問題報告熟練程度作為預(yù)測因子(很多研究顯示,開發(fā)者的經(jīng)驗與其工作產(chǎn)出的質(zhì)量相關(guān)[44]),其中,問題報告是否是重復(fù)報告以問題的在Bugzilla中所記錄的Solution來標(biāo)定,Solution為DUPLICATE的為重復(fù)報告;問題報告的熟練程度以問題報告提交者在此之前所提交的問題數(shù)量來量化,由于熟練程度還與距離上一次提交問題報告的時間間隔存在一定的關(guān)聯(lián)性,我們將時間限制為半年內(nèi),即問題報告提交者在此之前半年內(nèi)所提交的問題數(shù)量(NR).只要該模型的判定能力強于隨機猜測即可達到實驗?zāi)康?模型如下所示:

其次,基于2013年的數(shù)據(jù)集進行模型的訓(xùn)練、測試及調(diào)整.我們選取了數(shù)據(jù)集中最近5年,即2008年1月1日(北京時間,下同)后得到解決的(有Solution的)問題報告.此外,問題的最終解決需要經(jīng)過一段時間的驗證,即發(fā)現(xiàn) Solution的錯誤并糾正,因此,數(shù)據(jù)集中最后一段時間的問題報告的 Solution有相對較高的不穩(wěn)定性,無法準(zhǔn)確地判斷其是否是重復(fù)問題報告.我們對關(guān)于DUPLICATE的Solution錯誤出現(xiàn)的頻率及其糾正時間進行了統(tǒng)計,發(fā)現(xiàn)有約 2%的報告存在這樣的錯誤,其中超過75%的報告在 1年內(nèi)得到了糾正.因此,我們過濾掉其中最后一年的問題報告,即保留2008年1月1日～2012年1月1日之間提交的問題報告,保證其中不準(zhǔn)確報告的數(shù)量小于 0.5%(2%×(1-75%))(由于部分錯誤的糾正需要 10年以上的時間,為了保證有足夠的數(shù)據(jù),本文以損失 1年的數(shù)據(jù)為代價使不準(zhǔn)確的報告數(shù)量控制在 0.5%以內(nèi)).對剩余報告,我們按照其被提交的先后順序選取了前80%作為訓(xùn)練數(shù)據(jù),而后20%作為測試數(shù)據(jù).訓(xùn)練結(jié)果見表3,可以看到,NR的系數(shù)顯著不為0,其解釋度為2.9%,這說明,該模型具備判定能力,滿足本示例的需求.

Table 3 Model training result表3 模型訓(xùn)練結(jié)果

模型 1的輸出值表征了一個問題報告是否是重復(fù)報告的概率,在應(yīng)用該模型做判定前還要設(shè)置一個閾值,當(dāng)模型的輸出大于這個閾值時,即判定該問題報告是重復(fù)的.為了選取合適的閾值,我們對輸入訓(xùn)練集得到的輸出的分布進行統(tǒng)計,每10%分位點取一個值(即10%,20%,30%,…,90%分位數(shù))作為9個候選的閾值,利用測試集分別評估選取不同閾值時模型的性能,模型的性能以F1-score,即準(zhǔn)確率與召回率的調(diào)和平均數(shù)的兩倍來度量.表4展示了在不同閾值下模型的性能,從中我們可以看到,在閾值為0.214 2(60%分位點)時,模型性能達到最優(yōu).

Table 4 Threshold selection and model performance in test表4 閾值選擇及模型在測試中的性能

接下來,我們探究在實際應(yīng)用中,選取這些閾值的模型是否也能夠有相同的表現(xiàn).我們使用 2016年數(shù)據(jù)集來模擬實際應(yīng)用的場景.同樣,考慮到問題處理結(jié)果的穩(wěn)定性,除去數(shù)據(jù)集中最后一年的問題報告,為了測試已有模型在未來應(yīng)用中的性能,選取2013年數(shù)據(jù)集收集1年之后所提交的新報告,即從2016年數(shù)據(jù)集中節(jié)選2014年1月～2015年1月的1年間提交的已解決的問題報告.實驗結(jié)果見表5,從中可以看到,60%分位點的閾值已不具有最佳的分類表現(xiàn),并且在新的數(shù)據(jù)集上無論選取哪個閾值,模型的F1-score都不如實驗階段的結(jié)果.為了探索其中的原因,我們首先比較了自變量NR在訓(xùn)練數(shù)據(jù)和實際應(yīng)用數(shù)據(jù)中的均值和平均數(shù),它們分別從40和15上升到 831和 43,發(fā)生了較大的改變;其次.我們使用新增數(shù)據(jù)對模型重新訓(xùn)練,結(jié)果表明,報告者近期提交報告的數(shù)量的解釋度遠(yuǎn)高于使用 2013年數(shù)據(jù)訓(xùn)練的模型(見表 6),也就是說,模型預(yù)測能力的下降是因為實驗中的模型參數(shù)已不再適用于新的應(yīng)用場景.而模型解釋度的提升反映出,隨著時間的推移而新增的數(shù)據(jù)出現(xiàn)了新的特點,我們推測在 2013年之后,Mozilla社區(qū)的一些實踐方法的優(yōu)化措施,例如Bugzilla問題報告引導(dǎo)程序的改進有效地訓(xùn)練了新手完成問題報告的能力.

Table 5 Threshold selection and model performance in application表5 閾值選擇及模型在實際應(yīng)用中的性能

Table 6 Result of model training with new data表6 使用新增數(shù)據(jù)進行模型訓(xùn)練的結(jié)果

4.2 數(shù)據(jù)可追溯性的應(yīng)用

本文第 2節(jié)闡釋了數(shù)據(jù)集構(gòu)建過程的可追溯性可以解決兩個方面的問題:一是數(shù)據(jù)集的適用范圍,當(dāng)數(shù)據(jù)使用者發(fā)現(xiàn)其他人定制的高層數(shù)據(jù)(例如FTDD數(shù)據(jù)集[30])中缺少了所需要的信息時,可以去回溯到層次1,尋找缺失的數(shù)據(jù),重新構(gòu)建層次 2的數(shù)據(jù);二是數(shù)據(jù)質(zhì)量的保障,由于整個數(shù)據(jù)集構(gòu)建的處理過程及中間數(shù)據(jù)都是公開的,任何人都可以對數(shù)據(jù)的處理腳本進行測試,對數(shù)據(jù)進行比對,發(fā)現(xiàn)數(shù)據(jù)存在的缺陷或者局限,并評估他們對上層分析結(jié)果的影響.在下面兩個小節(jié)中,我們繼續(xù)以 Mozilla問題追蹤數(shù)據(jù)集為例,分別展示面向這兩方面問題的應(yīng)用.

4.2.1 數(shù)據(jù)的定制與適用范圍

定制化的數(shù)據(jù)為解決某些特定的問題提供了一定的便利.在第2.2節(jié)中我們提到了Habayeb等人的FTDD數(shù)據(jù)集[30],該數(shù)據(jù)集記錄了缺陷處理過程中的各類事件及其發(fā)生時間,可以幫助人們研究它們發(fā)生的模式及產(chǎn)生的影響.該數(shù)據(jù)集以Firefox所使用的Bugzilla問題追蹤數(shù)據(jù)為原始數(shù)據(jù),作者編碼了3大類10種事件,據(jù)此提取出每個缺陷報告中的事件.按照本文所提出的數(shù)據(jù)層次的概念,該數(shù)據(jù)集屬于定制層,即層次2或?qū)哟?+的數(shù)據(jù).由于具有同源性,該數(shù)據(jù)集可以由我們Mozilla問題追蹤數(shù)據(jù)集中層次1的數(shù)據(jù)加工而成.圖8所示為該數(shù)據(jù)集的數(shù)據(jù)模型,可以看到,相對于原始數(shù)據(jù),每個問題丟失了一部分信息,比如缺陷報告的優(yōu)先級、嚴(yán)重程度等屬性,缺陷報告的標(biāo)題、具體描述等文本信息.如果某個研究者想要研究不同類型的缺陷的處理模式,由于缺少這些問題屬性和描述,FTDD數(shù)據(jù)集并不能提供相應(yīng)的數(shù)據(jù)支撐.

層次化的數(shù)據(jù)集為解決這種定制數(shù)據(jù)應(yīng)用范圍有限的問題提供了有效的解決途徑.對于缺陷的類型,我們可以從很多角度進行分析,可以按問題所屬的產(chǎn)品、模塊分類,也可以按缺陷報告的優(yōu)先級、嚴(yán)重程度分類,還可以利用主題生成模型從缺陷的描述文本中挖掘主題并根據(jù)主題對缺陷報告進行分類.因此,我們嘗試回溯到層次1,對相關(guān)的信息進行再提取,包括缺陷報告的4種屬性(所屬產(chǎn)品、所屬模塊、優(yōu)先級、嚴(yán)重程度)以及每個報告的標(biāo)題和描述.之后,根據(jù)缺陷的 ID,我們將這些信息關(guān)聯(lián)到 FTDD數(shù)據(jù)中的每一個缺陷報告,構(gòu)建了一個新的如圖9所示的層次2數(shù)據(jù)集,它可以支撐不同類型缺陷的處理模式的研究.FTDD的作者在相關(guān)文獻中同樣提到了數(shù)據(jù)集擴展的問題,但沒有說明如何獲取擴展所需的數(shù)據(jù),而當(dāng)該數(shù)據(jù)集以層次化的方法構(gòu)建與使用時,這種擴展在實際應(yīng)用中的可行性將大為增加.

4.2.2 數(shù)據(jù)質(zhì)量的保障

產(chǎn)品質(zhì)量是消費者們最為關(guān)心的一種屬性.很多食品生產(chǎn)廠商通過使食品生產(chǎn)過程可追溯[45],讓每一個生產(chǎn)環(huán)節(jié)公開、可查驗來保證食品的質(zhì)量.同樣,通過使數(shù)據(jù)集的構(gòu)建過程可追溯來保證其面向最終用戶的質(zhì)量同樣值得數(shù)據(jù)發(fā)布者們嘗試.層次化的Mozilla數(shù)據(jù)集實現(xiàn)了數(shù)據(jù)集構(gòu)建過程的可追溯.除了直接面向數(shù)據(jù)使用者的定制數(shù)據(jù)外,我們還保留了定制數(shù)據(jù)構(gòu)建的全過程:在層次 0,有從數(shù)據(jù)源獲取的全部原始的數(shù)據(jù)和數(shù)據(jù)獲取的描述及腳本.在層次 1,有將原始數(shù)據(jù)標(biāo)準(zhǔn)化后的中間數(shù)據(jù)及進行標(biāo)準(zhǔn)化處理的腳本.數(shù)據(jù)集構(gòu)建的所有環(huán)節(jié)都是可查驗的,當(dāng)數(shù)據(jù)使用者在使用過程中發(fā)現(xiàn)了可疑的問題時可以追溯到上述任意一個處理環(huán)節(jié),查找問題的根源.

下面是我們在使用該數(shù)據(jù)集時所遇到的一個典型的例子.當(dāng)我們利用Bugzilla用戶的郵件地址來識別不同的用戶時,發(fā)現(xiàn)2011年數(shù)據(jù)集中有一些用戶的郵件地址并不完整.這很可能會導(dǎo)致同一個用戶被當(dāng)作不同的用戶來處理.為了查找問題的根源,我們?nèi)〉煤胁煌暾刂返膯栴}報告的ID,直接在 Mozilla的Bugzilla頁面中進行查詢,此時看到的郵件地址是完整的,也就是說,問題出在了數(shù)據(jù)集構(gòu)建的某個環(huán)節(jié)上.我們首先從層次0的原始數(shù)據(jù)開始排查,結(jié)果發(fā)現(xiàn),原始數(shù)據(jù)中這些郵件地址已不完整.這說明,我們的頁面下載腳本存在問題.Bugzilla有這樣一種訪問規(guī)則:只有登錄的用戶才可以查看其他用戶的完整郵件地址,因此,數(shù)據(jù)下載的腳本要進行登錄操作并在下載過程中保持登錄狀態(tài).雖然之前的腳本中有登錄機制,但存在不能保證登錄狀態(tài)的缺陷,部分?jǐn)?shù)據(jù)的下載是在未登錄狀態(tài)下進行的,因而沒有獲取到完整的用戶郵件地址.據(jù)此,我們修復(fù)了該腳本,提高了下載到的數(shù)據(jù)的質(zhì)量.

5 結(jié)束語

共享數(shù)據(jù)集的構(gòu)建與使用是提高軟件開發(fā)活動數(shù)據(jù)分析效率的一種途徑,而現(xiàn)有工作存在對數(shù)據(jù)可用性欠考慮的問題,直接威脅數(shù)據(jù)質(zhì)量與數(shù)據(jù)分析結(jié)果的有效性.為此,本文提出一種層次化、多版本化的數(shù)據(jù)集構(gòu)建與使用方法,通過劃分不同的數(shù)據(jù)層建立數(shù)據(jù)的可追溯性,通過多版本數(shù)據(jù)的收集納入可能出現(xiàn)的數(shù)據(jù)變化.利用這兩項設(shè)計,使用者可以驗證、提高數(shù)據(jù)質(zhì)量和數(shù)據(jù)分析結(jié)果的有效性.目前,我們已在該方法框架下完成了 Mozilla問題追蹤數(shù)據(jù)集的構(gòu)建與使用,本文中也分享了我們的相關(guān)經(jīng)驗,驗證了該方法的有效性.近期,我們注意到有些工作同樣嘗試了在定制數(shù)據(jù)之外提供原始數(shù)據(jù),以此方便數(shù)據(jù)使用者開展更多的分析,例如 Beller等人的 TravisTorrent數(shù)據(jù)集[46].在未來工作中,我們將繼續(xù)實踐該方法,構(gòu)建其他類型軟件開發(fā)活動的數(shù)據(jù)集,如代碼審查等.我們也將繼續(xù)使用層次化、多版本化的數(shù)據(jù)集開展軟件開發(fā)問題的研究,積累更多的經(jīng)驗,進一步完善該方法.特別地,當(dāng)數(shù)據(jù)集的層次2和層次2+中積累了紛雜的定制數(shù)據(jù)時,基于信息檢索等方法,實現(xiàn)面向特定用戶需求的自動化數(shù)據(jù)推薦.此外,數(shù)據(jù)規(guī)模的不斷擴大也會給數(shù)據(jù)集的使用帶來新的挑戰(zhàn),我們在未來也將嘗試借鑒Gousios等人的方法[7,17],通過分布式、P2P等方式使大規(guī)模數(shù)據(jù)的存儲與訪問更為高效.