涂菲菲,周明輝

1(高可信軟件技術(shù)教育部重點實驗室(北京大學(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ā)活動數(shù)據(jù).軟件開發(fā)活動數(shù)據(jù)覆蓋范圍非常廣,例如代碼提交[1]、功能需求的討論[2]、開發(fā)者在集成開發(fā)環(huán)境中的操作步驟[3]等.軟件開發(fā)活動數(shù)據(jù)被廣泛應(yīng)用于軟件開發(fā)過程中的各種決策,例如比較不同軟件方法之間的效果[1]、估算開發(fā)者的生產(chǎn)效率[4]、預(yù)測軟件質(zhì)量[5].

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

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

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

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

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

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

1 背景介紹

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

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

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

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

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

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

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

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

Fig.1 Basic information of issue report of #212077 in Gnome圖1 Gnome項目的212077號問題報告的基本信息

Fig.2 Activity history of issue report of #667796 in Gnome圖2 Gnome項目的667796號問題報告的歷史活動

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

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

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

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

2 研究方法

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

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

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

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

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

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

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

如圖4所示,我們根據(jù)問題可能產(chǎn)生的時間點,即數(shù)據(jù)產(chǎn)生階段、數(shù)據(jù)收集階段和數(shù)據(jù)使用階段,將數(shù)據(jù)質(zhì)量問題分為3類.數(shù)據(jù)產(chǎn)生階段的數(shù)據(jù)質(zhì)量問題包括前文提到過的“任務(wù)完成時間”的陷阱、問題追蹤數(shù)據(jù)的創(chuàng)建時間錯誤和版本控制數(shù)據(jù)中的時間問題.數(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ā)活動數(shù)據(jù)的數(shù)據(jù)質(zhì)量問題產(chǎn)生的3個階段

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

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

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

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

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

3.1.1 問題報告的創(chuàng)建時間錯誤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.2 郵箱地址的問題

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

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

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

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

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

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

在前面的分析中可以看出,有的數(shù)據(jù)質(zhì)量問題很容易理解,比較容易發(fā)現(xiàn),例如問題報告的創(chuàng)建時間錯誤,通過常識和統(tǒng)計分析及數(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ù)或者存在誤解,都會對研究結(jié)果產(chǎn)生影響.Mockus[19]認(rèn)為,理解數(shù)據(jù)產(chǎn)生的上下文應(yīng)至少包含以下幾點:1) 數(shù)據(jù)產(chǎn)生的方式,例如數(shù)據(jù)是由系統(tǒng)自動產(chǎn)生還是人工輸入、是否存在缺省值;2) 數(shù)據(jù)是否存在修改/刪除/過濾/缺損的情況,以及這些被修改/刪除/過濾/缺損的數(shù)據(jù)對結(jié)果是否有影響.

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

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

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

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

4.2 問題的修正

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

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

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

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

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

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

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

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

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

5 總結(jié)與展望

高質(zhì)量的數(shù)據(jù)是對軟件開發(fā)實踐進(jìn)行分析、預(yù)測、推薦的基礎(chǔ).隨著越來越多的工作圍繞軟件活動開發(fā)數(shù)據(jù)展開,也逐漸有一些工作認(rèn)識到數(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ì)量問題會得到越來越多的關(guān)注(鑒于智能軟件開發(fā)對于數(shù)據(jù)的依賴).同時希望有越來越多的努力構(gòu)建出可靠的數(shù)據(jù)集,或者構(gòu)建相應(yīng)的方法來產(chǎn)生可靠的數(shù)據(jù)集.未來工作我們將重點關(guān)注用自動化的方法來檢測和修正問題數(shù)據(jù).