涂菲菲,周明輝

1(高可信軟件技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室(北京大學(xué)),北京 100871)

2(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院,北京 100871)

軟件開發(fā)支持工具(例如問題追蹤系統(tǒng)、版本控制系統(tǒng))已被廣泛應(yīng)用于開源和商業(yè)軟件的開發(fā)中,這些軟件開發(fā)支持工具在使用過程中產(chǎn)生了大量的數(shù)據(jù),這些數(shù)據(jù)統(tǒng)稱為軟件開發(fā)活動(dòng)數(shù)據(jù).軟件開發(fā)活動(dòng)數(shù)據(jù)覆蓋范圍非常廣,例如代碼提交[1]、功能需求的討論[2]、開發(fā)者在集成開發(fā)環(huán)境中的操作步驟[3]等.軟件開發(fā)活動(dòng)數(shù)據(jù)被廣泛應(yīng)用于軟件開發(fā)過程中的各種決策,例如比較不同軟件方法之間的效果[1]、估算開發(fā)者的生產(chǎn)效率[4]、預(yù)測軟件質(zhì)量[5].

軟件開發(fā)活動(dòng)數(shù)據(jù)的廣泛使用,使其數(shù)據(jù)質(zhì)量受到了越來越多的關(guān)注.如果軟件開發(fā)活動(dòng)數(shù)據(jù)存在質(zhì)量問題,這可能使得基于問題數(shù)據(jù)的方法、軟件產(chǎn)生的結(jié)果存在偏差,甚至無效.例如,Kim等人[6]在利用問題追蹤數(shù)據(jù)智能化預(yù)測任務(wù)完成時(shí)間的工作中,將問題報(bào)告被標(biāo)記為“已解決”的時(shí)間點(diǎn)視為該任務(wù)完成的時(shí)刻.然而Zheng等人[7]發(fā)現(xiàn):任務(wù)完成的時(shí)間存在問題——開發(fā)者在完成任務(wù)后可能并不會(huì)及時(shí)將問題報(bào)告標(biāo)記為“已解決”,而是在之后清理問題追蹤系統(tǒng)時(shí),通過腳本進(jìn)行批量處理,即“任務(wù)完成時(shí)間”并不能真正代表任務(wù)被解決的時(shí)刻.因此,Kim等人的結(jié)果存在偏差.

雖然已有一些研究工作注意到了數(shù)據(jù)質(zhì)量問題[7-9],但文獻(xiàn)中往往只隱式地提及這些數(shù)據(jù)質(zhì)量問題,缺乏對這些數(shù)據(jù)質(zhì)量問題進(jìn)行綜合分析的工作.并且數(shù)據(jù)質(zhì)量問題并沒有引起足夠的重視,多數(shù)工作并不會(huì)提及其數(shù)據(jù)處理的細(xì)節(jié),例如數(shù)據(jù)獲取來源、數(shù)據(jù)質(zhì)量情況、數(shù)據(jù)預(yù)處理步驟等.為了揭示潛在的數(shù)據(jù)質(zhì)量問題,以更好地幫助軟件開發(fā)活動(dòng)數(shù)據(jù)的應(yīng)用,本文主要研究回答以下兩個(gè)問題.

1)軟件開發(fā)活動(dòng)數(shù)據(jù)可能存在哪些質(zhì)量問題?

2)如何發(fā)現(xiàn)和解決軟件開發(fā)活動(dòng)數(shù)據(jù)的質(zhì)量問題?

本文通過文獻(xiàn)調(diào)研和訪談,并基于自有經(jīng)驗(yàn)對數(shù)據(jù)進(jìn)行分析,總結(jié)出 9種潛在的數(shù)據(jù)質(zhì)量問題,覆蓋了數(shù)據(jù)產(chǎn)生、數(shù)據(jù)收集、數(shù)據(jù)使用等3個(gè)階段,并提出方法以幫助對數(shù)據(jù)問題的發(fā)現(xiàn)和修正.

本文第1節(jié)主要介紹相關(guān)背景.第2節(jié)介紹本文的研究方法.第3節(jié)從數(shù)據(jù)質(zhì)量問題覆蓋的3個(gè)階段出發(fā),對軟件開發(fā)活動(dòng)數(shù)據(jù)的質(zhì)量問題進(jìn)行詳細(xì)介紹.第 4節(jié)總結(jié)發(fā)現(xiàn)和解決軟件開發(fā)活動(dòng)數(shù)據(jù)質(zhì)量問題的方法.最后對本文工作進(jìn)行總結(jié)并展望未來工作.

1 背景介紹

常見的軟件開發(fā)活動(dòng)數(shù)據(jù)包括問題追蹤數(shù)據(jù)和版本控制數(shù)據(jù).

· 問題追蹤數(shù)據(jù)是指在項(xiàng)目開發(fā)過程中出現(xiàn)的各種缺陷以及新增加的功能需求等的解決過程留下的數(shù)據(jù),每個(gè)缺陷或者功能需求被稱為一個(gè)問題(issue).每個(gè)問題都包含一些特定信息,如誰發(fā)現(xiàn)的這個(gè)問題、這個(gè)問題被分配給誰來解決、這個(gè)問題的當(dāng)前狀態(tài)、這個(gè)問題的優(yōu)先級(jí)等等.問題報(bào)告的數(shù)量能在一定程度上反映代碼的質(zhì)量,問題報(bào)告的解決速度能夠反映開源項(xiàng)目的活躍程度等,因此,問題追蹤數(shù)據(jù)對于分析軟件項(xiàng)目的最佳實(shí)踐具有重要意義.

· 版本控制數(shù)據(jù)是指代碼庫每一次變更的歷史數(shù)據(jù),每次代碼更新都被稱為一個(gè)代碼提交(commit).每次代碼提交記錄了修改的原因、誰做了修改、修改了什么.版本控制數(shù)據(jù)不僅記錄了當(dāng)前的代碼庫,還記錄了整個(gè)代碼庫演化的過程,這些數(shù)據(jù)對于分析項(xiàng)目的歷史、當(dāng)前狀態(tài)以及未來都非常有價(jià)值.

1.1 問題追蹤數(shù)據(jù)

問題追蹤系統(tǒng)主要用于幫助開發(fā)人員追蹤軟件缺陷和需求,目前最常見的問題追蹤系統(tǒng)有 Bugzilla和JIRA等.

對于每個(gè)問題報(bào)告,問題追蹤系統(tǒng)記錄了報(bào)告的基本信息和報(bào)告的歷史活動(dòng)兩部分.

· 第1部分是報(bào)告的基本信息,主要包括序列號(hào)、報(bào)告標(biāo)題、報(bào)告人(reporter)、問題描述(description)、報(bào)告當(dāng)前的狀態(tài)(status)、處理意見(resolution)、問題產(chǎn)生的環(huán)境等信息,如圖1所示.

· 問題追蹤數(shù)據(jù)具有一個(gè)特點(diǎn):問題報(bào)告的信息有可能隨著時(shí)間而發(fā)生改變.例如,一個(gè)問題被報(bào)告到問題追蹤系統(tǒng)之后,會(huì)被其他人評論,會(huì)被調(diào)整優(yōu)先級(jí),在問題解決之后其狀態(tài)會(huì)被標(biāo)記為“已解決”狀態(tài),甚至在關(guān)閉之后被重新打開.這些操作都會(huì)使該問題報(bào)告的信息發(fā)生變動(dòng).因此,問題報(bào)告的第二部分是報(bào)告的歷史活動(dòng),如圖2所示.表中的每一行記錄了對報(bào)告的一次修改,記錄的內(nèi)容包括修改人(who)、修改時(shí)間(when)、修改域(what)、修改前的值(removed)和修改后的值(added).

Fig.1 Basic information of issue report of #212077 in Gnome圖1 Gnome項(xiàng)目的212077號(hào)問題報(bào)告的基本信息

Fig.2 Activity history of issue report of #667796 in Gnome圖2 Gnome項(xiàng)目的667796號(hào)問題報(bào)告的歷史活動(dòng)

1.2 版本控制數(shù)據(jù)

版本控制系統(tǒng)的核心要求是能夠方便團(tuán)隊(duì)協(xié)同開發(fā)以及記錄歷史版本,目前最常見的版本控制系統(tǒng)有Git、Mercurial、SVN 和 CVS等.

版本控制系統(tǒng)在代碼提交日志里記錄了開發(fā)者的每次代碼提交信息.如圖3所示,開發(fā)者的一次代碼提交,一般包括如下信息:提交者、作者、代碼提交的時(shí)間、代碼修改的時(shí)間、對該次提交的注解、修改的文件以及對每個(gè)文件修改的內(nèi)容.

Fig.3 A code commit log in Linux kernel圖3 Linux kernel項(xiàng)目的一條代碼提交日志

2 研究方法

問題追蹤數(shù)據(jù)和版本控制數(shù)據(jù)記錄了軟件從需求到代碼實(shí)現(xiàn)的過程,是軟件開發(fā)中非常重要的數(shù)據(jù).本文研究主要針對這兩類數(shù)據(jù).

為了對數(shù)據(jù)質(zhì)量問題進(jìn)行全面的總結(jié),我們首先在DBLP數(shù)據(jù)庫中進(jìn)行檢索,時(shí)間范圍是2000年～2017年,檢索時(shí)采用的英文關(guān)鍵詞包括“bug report”“issue report”“code repository”“software repository”,共檢索到 501 篇文章;然后,對檢索出的論文,通過人工審查方式移除掉與研究問題無關(guān)的論文,并通過查閱相關(guān)論文的參考文獻(xiàn)和相關(guān)研究人員發(fā)表的論文列表來進(jìn)一步識(shí)別出遺漏的論文.

進(jìn)一步地,我們基于自身的研究和實(shí)踐經(jīng)驗(yàn),對Gnome、Mozilla和Linux kernel數(shù)據(jù)進(jìn)行分析,觀察可能的錯(cuò)誤所在,并跟研究社區(qū)進(jìn)行互動(dòng)以理解數(shù)據(jù)問題存在的廣度與深度.

在調(diào)研的過程中,我們發(fā)現(xiàn)許多工作并不會(huì)清楚地說明論文中使用的數(shù)據(jù)集的來源,對數(shù)據(jù)進(jìn)行的預(yù)處理也很少提及,例如,Tamrawi等人[10]在任務(wù)分配的工作中并沒有提及如何建立郵箱地址和獨(dú)立開發(fā)者之間的關(guān)聯(lián)關(guān)系.另外,在調(diào)研的過程中,我們?nèi)コ恕皢栴}報(bào)告錯(cuò)誤分類”這一類已經(jīng)非常有影響力的工作.我們更多關(guān)注的是在軟件開發(fā)活動(dòng)數(shù)據(jù)的分析中,容易忽略的數(shù)據(jù)質(zhì)量問題.

3 數(shù)據(jù)質(zhì)量問題

本節(jié)回答第1個(gè)研究問題:軟件開發(fā)活動(dòng)數(shù)據(jù)可能存在哪些質(zhì)量問題?

數(shù)據(jù)質(zhì)量問題可能產(chǎn)生于與數(shù)據(jù)有關(guān)的任何階段,其產(chǎn)生的原因也多種多樣.在使用軟件開發(fā)支持工具的過程中,工具記錄了與開發(fā)活動(dòng)相關(guān)的數(shù)據(jù),這個(gè)過程為數(shù)據(jù)的產(chǎn)生過程.數(shù)據(jù)使用者通過各種方式,將軟件開發(fā)支持工具記錄的數(shù)據(jù)收集到本地,這個(gè)過程為數(shù)據(jù)的收集過程.數(shù)據(jù)使用者基于自身對數(shù)據(jù)的理解,利用數(shù)據(jù)解決各種研究問題,這個(gè)過程為數(shù)據(jù)的使用過程.

如圖4所示,我們根據(jù)問題可能產(chǎn)生的時(shí)間點(diǎn),即數(shù)據(jù)產(chǎn)生階段、數(shù)據(jù)收集階段和數(shù)據(jù)使用階段,將數(shù)據(jù)質(zhì)量問題分為3類.數(shù)據(jù)產(chǎn)生階段的數(shù)據(jù)質(zhì)量問題包括前文提到過的“任務(wù)完成時(shí)間”的陷阱、問題追蹤數(shù)據(jù)的創(chuàng)建時(shí)間錯(cuò)誤和版本控制數(shù)據(jù)中的時(shí)間問題.數(shù)據(jù)收集階段的數(shù)據(jù)質(zhì)量問題包括爬取數(shù)據(jù)不完整問題和隱私保護(hù)和安全保護(hù)等導(dǎo)致的數(shù)據(jù)不完整問題.數(shù)據(jù)使用階段的數(shù)據(jù)質(zhì)量問題包括未來數(shù)據(jù)泄露問題、郵箱地址的問題、版本控制數(shù)據(jù)中關(guān)于作者與提交者的問題.

Fig.4 Three phases of data quality problems of software developemt activity data圖4 軟件開發(fā)活動(dòng)數(shù)據(jù)的數(shù)據(jù)質(zhì)量問題產(chǎn)生的3個(gè)階段

不同階段的數(shù)據(jù)問題具有不同的特性.數(shù)據(jù)產(chǎn)生階段的問題通常是因?yàn)檐浖_發(fā)流程(支持工具或基礎(chǔ)設(shè)施)等所造成的數(shù)據(jù)使用者無法控制的問題.數(shù)據(jù)收集階段的問題多數(shù)可以通過優(yōu)化數(shù)據(jù)收集方法而得到解決或者部分解決,屬于部分可控.數(shù)據(jù)使用階段的問題在本文中多指“數(shù)據(jù)誤用問題”,即數(shù)據(jù)使用者忽略了數(shù)據(jù)本身的某些特征,誤用數(shù)據(jù)導(dǎo)致問題.這類問題往往較為隱蔽不易發(fā)現(xiàn),需要數(shù)據(jù)使用者對數(shù)據(jù)有深刻的理解.

這 9個(gè)數(shù)據(jù)質(zhì)量問題有些源自數(shù)據(jù)經(jīng)驗(yàn),有些是從文獻(xiàn)中歸納總結(jié)的.為了使本文更具實(shí)踐價(jià)值,對于每一個(gè)數(shù)據(jù)問題,我們列出其影響的項(xiàng)目.如果數(shù)據(jù)問題源于數(shù)據(jù)經(jīng)驗(yàn),那么其影響的項(xiàng)目就是指Gnome、Mozilla、Linux kernal;如果數(shù)據(jù)問題源于文獻(xiàn)調(diào)研,那么除了Gnome、Mozilla、Linux kernal,其影響的項(xiàng)目還包括相應(yīng)文獻(xiàn)中涉及的項(xiàng)目.表1列出了這9個(gè)數(shù)據(jù)質(zhì)量問題的來源和影響的項(xiàng)目.

Table 1 Nine data quality problems of software developemt activity data表1 軟件開發(fā)活動(dòng)數(shù)據(jù)的9個(gè)數(shù)據(jù)質(zhì)量問題

3.1 數(shù)據(jù)產(chǎn)生階段的數(shù)據(jù)質(zhì)量問題

數(shù)據(jù)產(chǎn)生階段的數(shù)據(jù)質(zhì)量問題主要是指,記錄在軟件開發(fā)支持工具中的數(shù)據(jù)并不能真實(shí)地反映真實(shí)的開發(fā)活動(dòng).這些有問題的數(shù)據(jù)產(chǎn)生的原因多種多樣,可能是軟件在記錄過程中出現(xiàn)了問題,也可能是由于特殊的軟件開發(fā)實(shí)踐.

對于許多工作來說,時(shí)間是一個(gè)非常重要的研究因素[6,16,17].直觀上,相較于其他文本數(shù)據(jù)而言,數(shù)據(jù)中記錄的時(shí)間的準(zhǔn)確性相對較高.因?yàn)闀r(shí)間的記錄形式簡單,通常為數(shù)字;含義明確,表示了某項(xiàng)活動(dòng)發(fā)生時(shí)的系統(tǒng)時(shí)間.而且時(shí)間通常是由軟件自動(dòng)記錄,不涉及人工輸入.但是我們所發(fā)現(xiàn)的數(shù)據(jù)產(chǎn)生階段的數(shù)據(jù)質(zhì)量問題全部與時(shí)間相關(guān).

3.1.1 問題報(bào)告的創(chuàng)建時(shí)間錯(cuò)誤

當(dāng)問題報(bào)告被創(chuàng)建時(shí),問題追蹤系統(tǒng)自動(dòng)記錄了該問題報(bào)告的創(chuàng)建時(shí)間.如圖2所示,在Gnome項(xiàng)目中,有一些問題報(bào)告的創(chuàng)建時(shí)間為1970年.這顯然是錯(cuò)誤的時(shí)間數(shù)據(jù),因?yàn)镚nome基金會(huì)最初建立于2000年(https://en.wikipedia.org/wiki/The_GNOME_Project),不可能在 1970年報(bào)告問題.這類問題的出現(xiàn)可能是源于軟件記錄的錯(cuò)誤.軟件系統(tǒng)中記錄的時(shí)間通常與UNIX時(shí)間戳對應(yīng),而UNIX時(shí)間戳是從1970年1月1日開始計(jì)算.因此當(dāng)軟件系統(tǒng)發(fā)生錯(cuò)誤時(shí),記錄的錯(cuò)誤時(shí)間通常在1970年附近.

3.1.2 版本控制數(shù)據(jù)中的時(shí)間問題

前文已經(jīng)介紹,版本控制系統(tǒng)中存在代碼作者和代碼提交者兩種不同的角色:代碼作者指實(shí)際寫代碼的人,代碼提交者指將寫好的代碼提交到版本控制系統(tǒng)中的人.根據(jù)活動(dòng)發(fā)生的時(shí)間看,代碼提交的時(shí)間不會(huì)早于寫代碼的時(shí)間.如果代碼提交者同時(shí)也是代碼作者,那么代碼提交的時(shí)間可能與寫代碼的時(shí)間相同,或者代碼提交的時(shí)間晚于寫代碼的時(shí)間.如果代碼提交者和代碼作者不同,那么代碼提交的時(shí)間晚于寫代碼的時(shí)間.在 Linux kernel中,存在一些代碼提交數(shù)據(jù),它們的代碼提交者和作者不同,但是代碼提交時(shí)間和寫代碼時(shí)間相同.根據(jù)前面的分析,這明顯是存在問題的數(shù)據(jù).那么在根據(jù)時(shí)間戳追溯代碼變更的過程時(shí),這個(gè)問題就會(huì)造成困擾.

3.1.3 “任務(wù)完成時(shí)間”的陷阱

“任務(wù)完成時(shí)間”的陷阱就是前文中舉例的問題.有許多工作利用問題報(bào)告的“任務(wù)完成時(shí)間”來預(yù)測一個(gè)新的問題需要的修復(fù)時(shí)間.計(jì)算方法是:一個(gè)問題報(bào)告的“任務(wù)完成時(shí)間”(即問題報(bào)告被標(biāo)記為“已解決”的時(shí)間)與該問題報(bào)告的創(chuàng)建時(shí)間之間的時(shí)間差,即為修復(fù)該問題所需的時(shí)間.Kim等人的工作就是通過這種計(jì)算方法來預(yù)測任務(wù)完成的時(shí)間.但是,Zheng等人發(fā)現(xiàn),如果將把問題報(bào)告標(biāo)記為“已解決”的人視為解決該問題的人,那么按照每人每天來統(tǒng)計(jì)工作量,則會(huì)發(fā)現(xiàn)有的人一天內(nèi)解決了超過200個(gè)問題.據(jù)估計(jì),每人每天解決9個(gè)問題即為上限.一人一天內(nèi)解決200個(gè)問題,這極大地超過了人的能力限制.因此,這明顯是有問題的數(shù)據(jù).Zheng等人發(fā)現(xiàn),開發(fā)者在完成任務(wù)后可能并不會(huì)及時(shí)將問題報(bào)告標(biāo)記為“已解決”,而是在之后清理問題追蹤系統(tǒng)時(shí),通過腳本進(jìn)行批量處理.因此,“任務(wù)完成時(shí)間”并不能真正代表任務(wù)被解決的時(shí)刻.而基于問題時(shí)間數(shù)據(jù)的研究結(jié)果產(chǎn)生了偏差.

3.2 數(shù)據(jù)收集階段的數(shù)據(jù)質(zhì)量問題

數(shù)據(jù)收集階段的數(shù)據(jù)質(zhì)量問題主要是指,數(shù)據(jù)使用者收集到的數(shù)據(jù)與軟件開發(fā)支持工具產(chǎn)生的數(shù)據(jù)不完全一樣,在這一節(jié)中列舉的數(shù)據(jù)質(zhì)量問題主要是指數(shù)據(jù)不完整.無論是通過爬蟲從網(wǎng)站上爬取數(shù)據(jù),還是通過API或者某些工具同步數(shù)據(jù),或者是直接從官方鏈接下載整理好的數(shù)據(jù)集,收集到的數(shù)據(jù)都可能會(huì)出現(xiàn)不完整的問題.

3.2.1 爬取數(shù)據(jù)不完整問題

在官方?jīng)]有提供數(shù)據(jù)集或者沒有可用 API下載數(shù)據(jù)的情況下,數(shù)據(jù)使用者們往往需要自己編寫爬蟲來爬取數(shù)據(jù).這就很容易遇到爬取數(shù)據(jù)不完整的情況[11].主要是兩點(diǎn)原因:網(wǎng)絡(luò)問題以及反爬蟲機(jī)制.網(wǎng)絡(luò)問題主要是指網(wǎng)頁加載慢、網(wǎng)絡(luò)延遲或者丟包等問題;反爬蟲機(jī)制是指被爬取的網(wǎng)站采取的防御措施.因?yàn)檫@兩點(diǎn)原因,當(dāng)使用爬蟲爬取數(shù)據(jù)時(shí),數(shù)據(jù)往往不完整.

3.2.2 隱私保護(hù)導(dǎo)致的數(shù)據(jù)不完整問題

開源社區(qū)為了保護(hù)貢獻(xiàn)者的隱私,會(huì)采取一些列措施使得外部人員無法批量獲取貢獻(xiàn)者名單和郵箱地址.如圖2所示,在Gnome社區(qū)中,如果不登錄賬號(hào),則無法看到貢獻(xiàn)者完整的郵箱地址[4].由于無法獲得完整的郵箱地址,只有開發(fā)者的昵稱,于是就喪失了郵件地址的域名這部分信息,而這部分信息往往包含了的背景信息,例如公司、學(xué)校等,因此可能會(huì)對開發(fā)者的背景分析造成困擾.

3.2.3 安全保護(hù)導(dǎo)致的數(shù)據(jù)不完整問題

Zhu等人的工作[11]提供了多個(gè)版本的Mozilla問題追蹤數(shù)據(jù),其中,2011和2012兩個(gè)版本為通過爬蟲爬取的數(shù)據(jù),2013的版本為Mozilla官方提供的數(shù)據(jù).通過3個(gè)版本的數(shù)據(jù)比較,他們發(fā)現(xiàn)有些問題報(bào)告Mozilla社區(qū)并不會(huì)開放出來,因?yàn)檫@些問題可能涉及到 Mozilla的核心安全.當(dāng)確認(rèn)這些報(bào)告并不會(huì)產(chǎn)生安全隱患后,這些報(bào)告會(huì)重新開放出來.這種數(shù)據(jù)問題對于研究“安全”相關(guān)問題的人來說非常重要,因?yàn)檫@些曾經(jīng)被隱藏起來的問題是真正涉及到安全的問題,是非常具有研究價(jià)值的對象.

3.3 數(shù)據(jù)使用階段的數(shù)據(jù)質(zhì)量問題

數(shù)據(jù)使用階段的數(shù)據(jù)質(zhì)量問題是指,數(shù)據(jù)使用者由于對數(shù)據(jù)產(chǎn)生的上下文不了解,而基于數(shù)據(jù)建立了錯(cuò)誤的假設(shè).

3.3.1 未來數(shù)據(jù)泄露問題

問題報(bào)告的屬性一直在隨著問題修復(fù)的進(jìn)程而被不斷修改.但是許多問題追蹤數(shù)據(jù)的使用者并沒有清楚地認(rèn)識(shí)到這一點(diǎn),并且沒有仔細(xì)區(qū)別實(shí)驗(yàn)中所使用的數(shù)據(jù)是否與研究問題的應(yīng)用場景所匹配.因此,可能產(chǎn)生在研究實(shí)驗(yàn)中,錯(cuò)誤的使用了來自“未來”的信息[12].例如在Sun等人[18]的研究中,他們使用問題報(bào)告的標(biāo)題進(jìn)行重復(fù)報(bào)告檢測.然而,問題報(bào)告的標(biāo)題會(huì)不斷修改.他們在實(shí)驗(yàn)中使用的問題報(bào)告的標(biāo)題已經(jīng)是經(jīng)過反復(fù)修改的.但是重復(fù)報(bào)告檢測的應(yīng)用場景,主要是發(fā)生在問題報(bào)告創(chuàng)建之初.因此,應(yīng)用問題報(bào)告創(chuàng)建時(shí)的原始標(biāo)題來檢測該報(bào)告是否重復(fù)更為合適.這種數(shù)據(jù)使用問題主要是因?yàn)闆]有理解“問題報(bào)告的屬性一直在隨著問題修復(fù)的進(jìn)程而被不斷修改”這一事實(shí),忽略了數(shù)據(jù)產(chǎn)生的上下文,對數(shù)據(jù)建立了錯(cuò)誤的假設(shè).這種錯(cuò)誤使用未來數(shù)據(jù)的問題也普遍存在于數(shù)據(jù)挖掘領(lǐng)域,也稱為數(shù)據(jù)泄露問題,是數(shù)據(jù)挖掘的十大錯(cuò)誤之一.

3.3.2 郵箱地址的問題

在軟件數(shù)據(jù)倉庫挖掘中,一個(gè)郵箱地址通常代表了一個(gè)開發(fā)者.但是一個(gè)郵箱地址并不是單純地對應(yīng)一個(gè)開發(fā)者,而是存在“多對一”和“一對多”的關(guān)系.一個(gè)郵箱地址對應(yīng)多個(gè)開發(fā)者,這種情況是指“一個(gè)郵箱地址”是公共郵箱(郵件列表地址)或者代表了特殊標(biāo)識(shí),例如 platform-help-inbox@eclipse.com 和 nobody@mozilla.org.前者可以被看作是問題報(bào)告分發(fā)過程中的 HUB,而后者則是代表了目前這個(gè)問題報(bào)告沒有指派,任何人都可以嘗試解決這個(gè)問題.在研究問題報(bào)告分配任務(wù)時(shí),如果目的是將問題報(bào)告分配給具體的真實(shí)開發(fā)者,那么“多對一”將引入噪音.多個(gè)郵箱地址對應(yīng)一個(gè)開發(fā)者,這是因?yàn)殚_發(fā)者擁有多個(gè)賬戶.這些賬戶的使用場景可能不同,例如,私人郵箱和公司郵箱;或者開發(fā)者所屬單位發(fā)生了變化,即開發(fā)者跳槽了,因此擁有多個(gè)賬戶.在研究開發(fā)者工作效率或者開發(fā)者網(wǎng)絡(luò)時(shí),“一對多”將使結(jié)果產(chǎn)生偏差.

3.3.3 版本控制數(shù)據(jù)中關(guān)于作者與提交者的問題

在版本控制系統(tǒng)的提交日志中,代碼提交者(committer)和代碼作者(author)代表了兩種不同的身份.Git將代碼提交者和代碼作者分別用committer和author記錄.但是SVN和CVS并沒有區(qū)分這兩種不同的身份.在SVN和CVS中,只存在author這個(gè)域,但是author實(shí)際記錄的卻是代碼提交者.因此,如果按照Git的習(xí)慣去理解SVN和CVS的數(shù)據(jù),以為author記錄的是代碼作者,那么就對數(shù)據(jù)有了誤解,產(chǎn)生了錯(cuò)誤的假設(shè).

4 數(shù)據(jù)質(zhì)量問題的發(fā)現(xiàn)和修正

本節(jié)回答第2個(gè)研究問題:如何發(fā)現(xiàn)和解決軟件開發(fā)活動(dòng)數(shù)據(jù)的質(zhì)量問題?

4.1 問題的發(fā)現(xiàn)

在前面的分析中可以看出,有的數(shù)據(jù)質(zhì)量問題很容易理解,比較容易發(fā)現(xiàn),例如問題報(bào)告的創(chuàng)建時(shí)間錯(cuò)誤,通過常識(shí)和統(tǒng)計(jì)分析及數(shù)據(jù)可視化可以發(fā)現(xiàn);但有的數(shù)據(jù)質(zhì)量問題比較隱蔽,例如未來數(shù)據(jù)泄露問題,需要對數(shù)據(jù)上下文有清楚的理解.

4.1.1 理解數(shù)據(jù)上下文

對于數(shù)據(jù)產(chǎn)生的上下文的理解,是應(yīng)用數(shù)據(jù)的基礎(chǔ).在第 3.3節(jié)中,我們反復(fù)強(qiáng)調(diào)了理解數(shù)據(jù)上下文的重要性.對數(shù)據(jù)理解不重復(fù)或者存在誤解,都會(huì)對研究結(jié)果產(chǎn)生影響.Mockus[19]認(rèn)為,理解數(shù)據(jù)產(chǎn)生的上下文應(yīng)至少包含以下幾點(diǎn):1) 數(shù)據(jù)產(chǎn)生的方式,例如數(shù)據(jù)是由系統(tǒng)自動(dòng)產(chǎn)生還是人工輸入、是否存在缺省值;2) 數(shù)據(jù)是否存在修改/刪除/過濾/缺損的情況,以及這些被修改/刪除/過濾/缺損的數(shù)據(jù)對結(jié)果是否有影響.

以“任務(wù)完成時(shí)間”的陷阱為例.在一般情況下,問題報(bào)告是在開發(fā)者解決了對應(yīng)的問題后,手動(dòng)將問題報(bào)告關(guān)閉并標(biāo)記為“已解決”.但是 Zheng等人發(fā)現(xiàn)一天之內(nèi)解決上百個(gè)問題報(bào)告,這已經(jīng)不是正常情況下的處理流程.據(jù)他們發(fā)現(xiàn),這種現(xiàn)象一般是由腳本批處理造成的.有 3個(gè)原因?qū)е铝诉@種特殊的問題報(bào)告處理流程:第一,問題報(bào)告由其他系統(tǒng)進(jìn)行管理,兩邊系統(tǒng)進(jìn)行數(shù)據(jù)同步,批量關(guān)閉了報(bào)告;第二,某個(gè)時(shí)間點(diǎn)集中清理問題追蹤系統(tǒng)中遺留的長期未解決的問題,將這些報(bào)告批量關(guān)閉;第三,當(dāng)版本控制系統(tǒng)中的問題修復(fù)了,其關(guān)聯(lián)的問題報(bào)告可能會(huì)被批量關(guān)閉.這3種情況下,數(shù)據(jù)都是系統(tǒng)自動(dòng)處理,而非人工手動(dòng)輸入.這就是因?yàn)閷?shù)據(jù)產(chǎn)生的方式理解不充分而產(chǎn)生的數(shù)據(jù)質(zhì)量問題.

4.1.2 統(tǒng)計(jì)分析及數(shù)據(jù)可視化

發(fā)現(xiàn)問題的一個(gè)有效手段是統(tǒng)計(jì)分析.最簡單地,統(tǒng)計(jì)數(shù)據(jù)的平均值、中位數(shù)、最大值、最小值、四分位數(shù),就可以對數(shù)據(jù)的分布有一個(gè)大概的認(rèn)識(shí).在這個(gè)過程中,如果有分布非常不均衡的現(xiàn)象,一些突出的問題已經(jīng)可以被識(shí)別出來,例如郵箱地址問題中的一對多問題.此外,還可以通過擬合一些概率分布模型來發(fā)現(xiàn)數(shù)據(jù)中的異常值.以“任務(wù)完成時(shí)間”的陷阱為例,Zheng等人通過泊松分布定位出了異常的“任務(wù)完成時(shí)間”.

數(shù)據(jù)可視化是數(shù)據(jù)分析中一個(gè)有效的技術(shù)手段[20].當(dāng)數(shù)據(jù)以直觀的圖形形式展示在分析者面前時(shí),分析者往往能夠一眼洞悉數(shù)據(jù)背后隱藏的信息并轉(zhuǎn)化知識(shí)以及智慧[21].通過數(shù)據(jù)可視化,可以對數(shù)據(jù)的整體走向有一個(gè)清楚的認(rèn)識(shí),對于其中的異常點(diǎn)也能夠輕而易舉的捕捉到.例如,在揭示“任務(wù)完成時(shí)間”陷阱的過程中,Zheng等人通過數(shù)據(jù)可視化展示出了該數(shù)據(jù)質(zhì)量問題日益嚴(yán)重的發(fā)展趨勢.另外,在可視化問題追蹤數(shù)據(jù)的過程中找到了1970年這個(gè)異常點(diǎn),因此發(fā)現(xiàn)了問題報(bào)告的創(chuàng)建時(shí)間錯(cuò)誤.

4.2 問題的修正

在發(fā)現(xiàn)了軟件開發(fā)活動(dòng)數(shù)據(jù)的質(zhì)量問題后,可以嘗試通過兩種方法對問題數(shù)據(jù)進(jìn)行修正來降低數(shù)據(jù)質(zhì)量問題帶來的負(fù)面影響,即利用冗余數(shù)據(jù)進(jìn)行修正和挖掘用戶行為模式進(jìn)行修正.所幸,豐富的軟件開發(fā)活動(dòng)數(shù)據(jù)資源使得這兩種數(shù)據(jù)修正方式成為可能.這兩種數(shù)據(jù)修正方法分別適用于不同的研究問題和背景:利用冗余數(shù)據(jù)進(jìn)行修正的方法能夠很好地適用于時(shí)間存在問題的數(shù)據(jù),例如“任務(wù)完成時(shí)間”陷阱;挖掘用戶行為模式進(jìn)行修正適用于需要進(jìn)行用戶身份識(shí)別的問題,例如郵箱地址的問題.數(shù)據(jù)問題的修正方法與研究問題和背景密切相關(guān),仔細(xì)分辨研究問題的動(dòng)機(jī)、背景,了解數(shù)據(jù)產(chǎn)生的上下文,不僅可以發(fā)現(xiàn)問題,也是修正數(shù)據(jù)必不可少的步驟.

4.2.1 利用冗余數(shù)據(jù)進(jìn)行修正

冗余數(shù)據(jù)是指,軟件開發(fā)活動(dòng)數(shù)據(jù)中與原數(shù)據(jù)用途、含義相近的數(shù)據(jù).在軟件開發(fā)活動(dòng)數(shù)據(jù)中,一項(xiàng)開發(fā)活動(dòng)可能在多個(gè)不同的系統(tǒng)或者相近的活動(dòng)中留下痕跡.這些就是互為冗余的數(shù)據(jù).特別強(qiáng)調(diào),這里的冗余并非貶義詞,而是指數(shù)據(jù)的意義相近(并非完全相同需要去除的冗余數(shù)據(jù)).

以“任務(wù)完成時(shí)間”的陷阱為例.冗余數(shù)據(jù)可能存在于同一個(gè)系統(tǒng)中,也可能存在于不同的系統(tǒng)中.“任務(wù)完成時(shí)間”的陷阱中,有問題的數(shù)據(jù)是問題報(bào)告被標(biāo)記為“已解決”的時(shí)間.這個(gè)數(shù)據(jù)原本是想表示該問題被解決的時(shí)間.但是當(dāng)它出現(xiàn)了問題,它就并不能起到應(yīng)有的作用了.因此,從這個(gè)數(shù)據(jù)原本表示的含義出發(fā),結(jié)合“已解決”時(shí)間產(chǎn)生的上下文,即與該數(shù)據(jù)相關(guān)的軟件開發(fā)活動(dòng),分別在同一個(gè)系統(tǒng)和不同的系統(tǒng)中尋找意思相近的數(shù)據(jù).在同一個(gè)系統(tǒng)中,即問題追蹤系統(tǒng)中,每一個(gè)問題報(bào)告的最后一條評論時(shí)間基本可以等視為問題被解決的時(shí)間.因?yàn)楫?dāng)一個(gè)問題被解決后,就很少會(huì)有人再去關(guān)注它、討論它.那么就可以將原先錯(cuò)誤的“任務(wù)完成時(shí)間”修改為更為準(zhǔn)確的問題報(bào)告最后一條評論時(shí)間.在不同的系統(tǒng)當(dāng)中,例如版本控制系統(tǒng),與該問題報(bào)告對應(yīng)的代碼的提交時(shí)間可以等視為問題為解決的時(shí)間.因?yàn)橥ǔＧ闆r下的處理流程就是:在代碼庫中提交了代碼修改,然后將問題報(bào)告標(biāo)記為“已解決”.這些都是從數(shù)據(jù)的含義出發(fā),理解了開發(fā)實(shí)踐過程,找到的解決方法.

這種方法也可以應(yīng)用到問題報(bào)告的創(chuàng)建時(shí)間的修正上,例如,可以用問題報(bào)告的第1條評論的時(shí)間或者第1次信息被修改的時(shí)候來預(yù)估問題報(bào)告的創(chuàng)建時(shí)間.利用冗余數(shù)據(jù)進(jìn)行修正的方法在修正軟件開發(fā)活動(dòng)的時(shí)間上具有一定的通用性,因?yàn)檐浖_發(fā)活動(dòng)是一系列連貫的活動(dòng),根據(jù)該項(xiàng)活動(dòng)前后的活動(dòng)數(shù)據(jù),就可以對原來錯(cuò)誤的數(shù)據(jù)進(jìn)行修正.

4.2.2 挖掘用戶行為模式進(jìn)行修正

軟件開發(fā)活動(dòng)數(shù)據(jù)記錄了軟件開發(fā)過程中開發(fā)者的一系列活動(dòng).軟件開發(fā)是一項(xiàng)連續(xù)的活動(dòng),每一個(gè)行為或活動(dòng)不可能單獨(dú)存在,也不會(huì)突然發(fā)生巨大的改變.我們假定一個(gè)用戶的行為模式是特定的,那么我們可以從歷史數(shù)據(jù)中挖掘出用戶的行為模式,進(jìn)而對問題數(shù)據(jù)進(jìn)行修正.

這里以郵箱地址的問題為例.在解決“多對一”的問題時(shí),除了根據(jù)用戶名的命名規(guī)則和相似度進(jìn)行識(shí)別,還可以通過挖掘用戶行為模式進(jìn)行修正.例如在版本控制數(shù)據(jù)中,這些郵件地址的作者或者代碼提交者如果有著相近或者相同的行為習(xí)慣,那么這些郵件地址就很有可能指向同一個(gè)人.在這個(gè)問題中,行為習(xí)慣包括編寫或者提交過的文件、提交日志的書寫風(fēng)格和工作時(shí)區(qū).如果多個(gè)不同的賬戶修改同樣的代碼文件,那他們可能指向同一個(gè)人.不同的開發(fā)者有著不同的代碼風(fēng)格,也有著不同的代碼日志風(fēng)格,如果多個(gè)賬戶的代碼提交日志的書寫風(fēng)格類似,那么他們可能指向同一個(gè)人.假定開發(fā)者的物理位置不會(huì)頻繁發(fā)生改變,那么如果多個(gè),例如有相同書寫風(fēng)格的賬戶的物理位置相近,他們就更可能指向同一個(gè)人,而在版本控制數(shù)據(jù)中,該信息可以從時(shí)區(qū)信息中提取出來.

同樣地,在識(shí)別“一對多”問題時(shí),也同樣可以通過挖掘用戶行為模式定位出那些公共賬號(hào),例如工作時(shí)區(qū).在開源開發(fā)中,開發(fā)者遍布世界各地.當(dāng)一個(gè)郵件地址對應(yīng)的時(shí)區(qū)信息經(jīng)常發(fā)生變化,具有較大不確定性,那么該賬號(hào)就很有可能是一個(gè)公共賬號(hào).

5 總結(jié)與展望

高質(zhì)量的數(shù)據(jù)是對軟件開發(fā)實(shí)踐進(jìn)行分析、預(yù)測、推薦的基礎(chǔ).隨著越來越多的工作圍繞軟件活動(dòng)開發(fā)數(shù)據(jù)展開,也逐漸有一些工作認(rèn)識(shí)到數(shù)據(jù)質(zhì)量的重要性并發(fā)現(xiàn)了數(shù)據(jù)中潛在的數(shù)據(jù)質(zhì)量問題.然而,人們對于軟件數(shù)據(jù)質(zhì)量問題的關(guān)注度還遠(yuǎn)不能匹配數(shù)據(jù)本身的重要性.因此,本文通過廣泛的文獻(xiàn)調(diào)研并深入分析數(shù)據(jù),總結(jié)出了9類數(shù)據(jù)質(zhì)量問題,并從發(fā)現(xiàn)問題和解決問題方面分別提出了建議.

我們相信,隨著智能化軟件開發(fā)的蓬勃發(fā)展,數(shù)據(jù)質(zhì)量問題會(huì)得到越來越多的關(guān)注(鑒于智能軟件開發(fā)對于數(shù)據(jù)的依賴).同時(shí)希望有越來越多的努力構(gòu)建出可靠的數(shù)據(jù)集,或者構(gòu)建相應(yīng)的方法來產(chǎn)生可靠的數(shù)據(jù)集.未來工作我們將重點(diǎn)關(guān)注用自動(dòng)化的方法來檢測和修正問題數(shù)據(jù).