汪文娟，李 兵，2，何 鵬

（1.武漢大學(xué)a.軟件工程國家重點(diǎn)實(shí)驗(yàn)室；b.復(fù)雜網(wǎng)絡(luò)研究中心，武漢430072；2.南京財(cái)經(jīng)大學(xué)江蘇省電子商務(wù)重點(diǎn)實(shí)驗(yàn)室，南京210046）

0 引言

近年來，物聯(lián)網(wǎng)、云計(jì)算技術(shù)等互聯(lián)網(wǎng)應(yīng)用逐漸深入和推廣，引發(fā)了軟件技術(shù)的變革，為適應(yīng)海量信息處理、用戶需求的個(gè)性化和多元化、軟件的服務(wù)化，新型軟件工程——群體軟件工程［1］應(yīng)運(yùn)而生，實(shí)現(xiàn)了軟件開發(fā)過程從封閉到開放，人員從精英到大眾，組織從工廠到社群，方法從機(jī)器工程到社會(huì)工程的轉(zhuǎn)變。典型的群體軟件開發(fā)實(shí)例，有蘋果的App Store和谷歌的Android應(yīng)用商店。隨著軟件工程的轉(zhuǎn)型，軟件系統(tǒng)的規(guī)模越來越大且開發(fā)過程越來越復(fù)雜，面對群體軟件開發(fā)的這一復(fù)雜特征，將軟件工程與“網(wǎng)絡(luò)科學(xué)”相結(jié)合，應(yīng)用網(wǎng)絡(luò)智能方法，開展對項(xiàng)目開發(fā)過程中面向群體的行為分析，為群體軟件開發(fā)特性研究和質(zhì)量保證提供有力支撐。

復(fù)雜網(wǎng)絡(luò)與軟件工程的交叉研究已引起了眾多學(xué)者的關(guān)注與認(rèn)可，相關(guān)研究成果［2－3］已發(fā)表在軟件工程領(lǐng)域的權(quán)威期刊上，具有廣闊的發(fā)展前景。軟件網(wǎng)絡(luò)的研究結(jié)合了復(fù)雜網(wǎng)絡(luò)和軟件工程理論，它以軟件系統(tǒng)的結(jié)構(gòu)特征為切入點(diǎn)，將復(fù)雜網(wǎng)絡(luò)的理論應(yīng)用到軟件工程領(lǐng)域，研究軟件這一類型的人工設(shè)計(jì)實(shí)現(xiàn)的系統(tǒng)是否也像社會(huì)和自然界中的網(wǎng)絡(luò)一樣具有復(fù)雜網(wǎng)絡(luò)的特性。目前，軟件網(wǎng)絡(luò)研究主要是對已有軟件采用逆向工程方法得出其中的組織結(jié)構(gòu)進(jìn)行分析，發(fā)現(xiàn)其中的復(fù)雜網(wǎng)絡(luò)特性，反映軟件系統(tǒng)的一些整體度量性質(zhì)。隨著軟件的網(wǎng)絡(luò)化趨勢越來越明顯，軟件與網(wǎng)絡(luò)的關(guān)系更加密不可分，用網(wǎng)絡(luò)的觀點(diǎn)來分析軟件，為軟件工程實(shí)踐提供了新的視角，也是現(xiàn)今軟件工程主要研究的問題之一。但軟件開發(fā)是一個(gè)社會(huì)性（“人”）和技術(shù)性（“軟件”和“網(wǎng)絡(luò)”）匯聚［4］的過程，很多研究只是從技術(shù)性出發(fā)，探索了軟件系統(tǒng)技術(shù)維度的復(fù)雜性，而軟件開發(fā)是一項(xiàng)人工參與的活動(dòng)，還涉及各類行為者的貢獻(xiàn)，即軟件開發(fā)的社會(huì)性，只有結(jié)合社會(huì)網(wǎng)絡(luò)分析，才能使得網(wǎng)絡(luò)化環(huán)境下軟件的各個(gè)組成部分構(gòu)成一個(gè)完整的生態(tài)系統(tǒng)。

軟件是由人開發(fā)的系統(tǒng)，是一個(gè)人與人交互的網(wǎng)絡(luò)，系統(tǒng)的結(jié)構(gòu)、功能和演化方向與人的交互有著密切的關(guān)聯(lián)。軟件的結(jié)構(gòu)可視為開發(fā)者間關(guān)系的一種折射。開發(fā)者合作關(guān)系的變動(dòng)與軟件的演化之間存在決定與反作用的關(guān)系。通過分析開發(fā)者網(wǎng)絡(luò)的演化過程，挖掘出開發(fā)者在軟件開發(fā)過程中的協(xié)作行為、活躍程度、貢獻(xiàn)價(jià)值，為管理者及其他開發(fā)人員的開發(fā)行為提供決策參考。

在對軟件進(jìn)行分析時(shí)已有研究遇到了很多難題，例如，軟件系統(tǒng)的數(shù)據(jù)很難得到，很少有現(xiàn)存的相關(guān)理論可供參考，開發(fā)者的邊緣學(xué)習(xí)以及團(tuán)隊(duì)人員間的遷移融合過程。幸運(yùn)的是，開源軟件的廣泛流行與發(fā)展，相比與商業(yè)軟件，它更能滿足人們的需要，促使越來越多的人自愿參與到開源軟件社區(qū)中。開源軟件的繁榮使得我們能夠便捷、快速地獲取到大量相關(guān)的數(shù)據(jù)，從而進(jìn)行相關(guān)的研究。通常一個(gè)成功的開源軟件在其生命周期中都會(huì)有一系列版本，針對軟件的每個(gè)版本，我們構(gòu)造相應(yīng)的開發(fā)者網(wǎng)絡(luò)，本文把開發(fā)者視為節(jié)點(diǎn)，把從事于同一個(gè)組件或包、類、方法開發(fā)的開發(fā)者間視為有一條合作邊，構(gòu)建開發(fā)者網(wǎng)絡(luò)。引入開發(fā)者活躍度指標(biāo)，通過該指標(biāo)探析社區(qū)開發(fā)者的角色演化趨勢。本文對一個(gè)成功的開源軟件Tomcat（http：／／tomcat.apache.org／）的10個(gè)版本的開發(fā)者網(wǎng)絡(luò)進(jìn)行實(shí)例分析。

據(jù)了解，關(guān)于開源軟件社區(qū)開發(fā)者的角色劃分，Nakakoji等［5］把開源軟件項(xiàng)目劃分為3類并提出將角色劃分為8類，即：被動(dòng)用戶、積極用戶、bug報(bào)告員、bug修復(fù)員、邊緣開發(fā)者、積極的開發(fā)者、核心人員、項(xiàng)目經(jīng)理。作者只是簡單地根據(jù)節(jié)點(diǎn)度對開發(fā)者進(jìn)行角色劃分，而衡量節(jié)點(diǎn)重要性的指標(biāo)目前已有很多，僅通過節(jié)點(diǎn)度無法很好地刻畫節(jié)點(diǎn)的重要性，因此，本文提出了一個(gè)活躍度指標(biāo)用于衡量開發(fā)者的活躍性，便于角色演化分析。另外，Xu等［6－7］進(jìn)一步對開發(fā)者的角色進(jìn)行劃分，數(shù)量由8類簡化為5類，最后又進(jìn)一步簡化為4類角色：即積極用戶，核心開發(fā)者，合作者，項(xiàng)目經(jīng)理。Borgatti［8］最早提出網(wǎng)絡(luò)的核心－邊緣結(jié)構(gòu)概念，并提出算法和測試驗(yàn)證該結(jié)構(gòu)的正確性。Crowston等［9］根據(jù)bug修復(fù)信息構(gòu)建網(wǎng)絡(luò)，闡述了開源軟件開發(fā)團(tuán)隊(duì)中的核心－邊緣結(jié)構(gòu)，提出一種確定開發(fā)團(tuán)隊(duì)核心成員的有效方法。Sureka等［10］挖掘缺陷追蹤系統(tǒng)中的信息，發(fā)現(xiàn)開發(fā)者合作網(wǎng)絡(luò)的洋蔥結(jié)構(gòu)，并把開發(fā)者分為核心、半邊緣、邊緣三類。除此之外，Pinzger等［11］研究了開發(fā)者貢獻(xiàn)網(wǎng)絡(luò)與軟件發(fā)布后缺陷數(shù)的關(guān)系，使用網(wǎng)絡(luò)中心性指標(biāo)衡量貢獻(xiàn)網(wǎng)絡(luò)的重要程度，指出中心模塊比非中心模塊有更多的缺陷傾向。在文獻(xiàn)［12］中，Crowston論證了中心性在跨項(xiàng)目和時(shí)間上的分布，實(shí)證了項(xiàng)目的核心成員變動(dòng)情況相對比較少，而且參與跨項(xiàng)目社區(qū)的情況也不多見。Wiggins等［13］對Fire和Gain兩個(gè)項(xiàng)目的中心勢動(dòng)態(tài)做了研究，發(fā)現(xiàn)兩個(gè)項(xiàng)目均隨時(shí)間變化趨向于分散化。Huang等［14］指出在開源軟件網(wǎng)絡(luò)中，節(jié)點(diǎn)的重要性遵循二八定律。以上工作主要是用中心性指標(biāo)來衡量節(jié)點(diǎn)的重要性，并用于缺陷分析與網(wǎng)絡(luò)整體趨勢分析。他們并沒有關(guān)注單個(gè)開發(fā)者的演化趨勢，以及網(wǎng)絡(luò)中典型演化模式的提取。

本文重點(diǎn)對一個(gè)項(xiàng)目不同版本階段的開發(fā)者網(wǎng)絡(luò)中開發(fā)者角色進(jìn)行演化分析，主要貢獻(xiàn)為：1）收集整理了Tomcat 6項(xiàng)目從2006—2010年10個(gè)版本的開發(fā)者修改日志和郵件列表信息，構(gòu)建每個(gè)版下的開發(fā)者網(wǎng)絡(luò)，便于后續(xù)研究者在提供的數(shù)據(jù)集上對本工作的重現(xiàn)與更深入的研究；2）提取了5類典型社區(qū)開發(fā)者演化模式和每類開發(fā)者擅長從事的工作類型，有利于開發(fā)者的角色預(yù)測與任務(wù)分配，為管理者提供決策參考。

1 研究方法

首先利用我們團(tuán)隊(duì)開發(fā)的聚焦爬蟲工具從svn日志與郵件列表信息中爬取開發(fā)者行為數(shù)據(jù)；然后根據(jù)項(xiàng)目的版本信息，把數(shù)據(jù)劃分為10個(gè)連續(xù)的版本，并依次根據(jù)開發(fā)者參與的任務(wù)構(gòu)建10個(gè)相應(yīng)的開發(fā)者網(wǎng)絡(luò)；基于所得的開發(fā)者網(wǎng)絡(luò)，對開發(fā)者的活躍度進(jìn)行演化分析，并基于開發(fā)者活躍度的演化趨勢把開發(fā)者劃分為5種類型，通過分析開發(fā)者活躍度與提交日志數(shù)之間關(guān)系的分布進(jìn)而衡量開發(fā)者貢獻(xiàn)度；最后，通過對日志信息的分類，得到每類開發(fā)者在不同任務(wù)上的實(shí)踐技能。

1.1 開發(fā)者網(wǎng)絡(luò)模型

本文選取了Apache軟件基金會(huì)（ASF）資助的一個(gè)典型的開源軟件項(xiàng)目－Tomcat作為實(shí)驗(yàn)案例，采用課題組自行開發(fā)的聚焦爬蟲工具爬取Tomcat 6從2006年到2010年的開發(fā)者日志和郵件列表信息，主要包括信息的鏈接URL，開發(fā)者的姓名，commit的主題及提交時(shí)間。根據(jù)提供的版本發(fā)布信息，將數(shù)據(jù)劃分為10個(gè)版本，考慮到有些版本相距時(shí)間只有幾天，我們只選取相隔至少1個(gè)月的版本作為實(shí)驗(yàn)版本，因此，表1中第一列只給出每個(gè)版本相應(yīng)的序號。在數(shù)據(jù)處理過程中，類似于已有文獻(xiàn)的處理方法，只選取了具有提交日志權(quán)限的開發(fā)者，于是部分邊緣用戶被排除在外，表1給出了每個(gè)版本的詳細(xì)信息。

在構(gòu)建開發(fā)者網(wǎng)絡(luò)過程中，用DevNet＝（V，E），V為網(wǎng)絡(luò)的節(jié)點(diǎn)集，E為連邊集。網(wǎng)絡(luò)中節(jié)點(diǎn)代表參與的開發(fā)者，如果開發(fā)者i，j參與同一工作線程的開發(fā)則被視為存在一條合作連邊eij＝1，否則eij＝0，本文沒有考慮兩個(gè)開發(fā)者間的合作次數(shù)，且兩個(gè)開發(fā)者之間的合作被視為是相互的。圖1是版本1的開發(fā)者網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

表1 版本信息Tab.1 Version information

圖1 版本1的開發(fā)者網(wǎng)絡(luò)Fig.1 The developer network of version 1

1.2 活躍度

活躍度是度量開發(fā)者的交際范圍以及衡量開發(fā)者重要性的指標(biāo)?；钴S度具體來說，就是開發(fā)者與多少人進(jìn)行過交互。在開發(fā)者網(wǎng)絡(luò)中，如果一個(gè)節(jié)點(diǎn)擁有更多的合作對象，那么這個(gè)節(jié)點(diǎn)所代表的開發(fā)者的活躍度越高。反之，活躍度很低的開發(fā)者與其他人建立的合作也相對少。因此，活躍度與節(jié)點(diǎn)的度息息相關(guān)，但又不簡單地等于節(jié)點(diǎn)度。本文用Activei表示開發(fā)者i的活躍度：

1.3 標(biāo)準(zhǔn)化

在進(jìn)行數(shù)據(jù)分析之前，通常要進(jìn)行數(shù)據(jù)標(biāo)準(zhǔn)化以減少實(shí)驗(yàn)偏差。已有的標(biāo)準(zhǔn)化方法很多，本文采用Min－Max標(biāo)準(zhǔn)化，Min－Max標(biāo)準(zhǔn)化是對原始數(shù)據(jù)進(jìn)行線性變換。設(shè)Min和Max分別為網(wǎng)絡(luò)中所有節(jié)點(diǎn)Active指標(biāo)值的最小值和最大值，將Active的一個(gè)原始值x通過Min－Max標(biāo)準(zhǔn)化映射成在區(qū)間［0，1］中的值x′：

對活躍度標(biāo)準(zhǔn)化后，計(jì)算相應(yīng)的rank值，即若Active′i∈［k，k＋0.1），0≤k≤0.9，則ranki＝k＊10＋1。最后，根據(jù)rank值找到對應(yīng)的活躍度等級。活躍度等級劃分的標(biāo)準(zhǔn)：7≤rank≤10，等級為高；4≤rank≤6，等級為中；1≤rank≤3，等級為低。

1.4 日志信息類型

在文獻(xiàn)［15］中，作者對5個(gè)開源軟件的bug庫進(jìn)行分析，發(fā)現(xiàn)很多bug報(bào)告實(shí)際上并不是修復(fù)bug，而是提出一個(gè)新功能或者提高系統(tǒng)性能等。他采用人工對bug報(bào)告進(jìn)行分類的方法，探究誤分類對缺陷預(yù)測的影響。類似于該文獻(xiàn)，我們對開發(fā)者日志信息類型分為6大類：BUG類，日志記錄了糾正性的維護(hù)任務(wù)：對源代碼進(jìn)行語義上的更改；RFE類，日志記錄了適應(yīng)性的維護(hù)任務(wù)：增加新功能；IMPR類，日志記錄了完備性的維護(hù)任務(wù)：提高系統(tǒng)整體性能；DOC類，日志記錄了外部網(wǎng)站或代碼文檔的更新；REFAC類，日志記錄了重構(gòu)源代碼的問題，通常由開發(fā)者提交；OTHER類，日志記錄了代碼移植，代碼清理，規(guī)范更改（非文檔和代碼），測試用例。

日志信息的分類規(guī)則為：如果出現(xiàn)空指針異常NullpointerException源代碼，需要進(jìn)行語義上的更改缺陷導(dǎo)致運(yùn)行時(shí)間或內(nèi)存出現(xiàn)問題，該日志歸類為BUG；如果出現(xiàn)非最優(yōu)算法和垃圾收集策略導(dǎo)致的資源問題（時(shí)間，內(nèi)存）要求對代碼，日志信息，文檔信息，異常信息，屬性字段進(jìn)行非語義上的修改或修復(fù)要求增加或刪除文檔和日志信息要求更新文檔或日志信息的內(nèi)容要求改變拋出異常的類型或信息要求變更支持新的輸入和輸出格式介紹已有功能的并發(fā)版本建議升級或修補(bǔ)第三方庫去解決問題要求按照規(guī)約／文檔修正已經(jīng)實(shí)現(xiàn)的功能，該日志歸類為IMPR（改進(jìn)請求）；如果要求實(shí)現(xiàn)一個(gè)新的接口或方法要求增加新功能要求支持新的對象類型，規(guī)范或標(biāo)準(zhǔn)，該日志歸類為RFE（功能請求）；如果由于丟失文檔或文檔過時(shí)而提交報(bào)告請求更新文檔或增刪文檔請求更新外部網(wǎng)站，該日志歸類為DOC（文檔請求）；如果請求將代碼移動(dòng)到其他包，類或方法中請求為變量，方法，類，包或配置文件重命名請求屬性在不同環(huán)境中的通用，該日志歸類為REFAC（重構(gòu)請求）；如果報(bào)告了違反java合同但是沒有導(dǎo)致異常的事件有關(guān)兼容性修補(bǔ)程序的建議任務(wù)不需要修改源代碼或文檔（如包裝，配置，下載），該日志歸類為OTHER。

按照以上規(guī)則對日志信息分類，便于后續(xù)部分對不同角色演化模式的開發(fā)者所從事的工作進(jìn)行對比分析。

2 實(shí)證分析

實(shí)驗(yàn)對象的選取是影響實(shí)證分析結(jié)果的重要因素之一，本文定義了一些篩選標(biāo)準(zhǔn)用于實(shí)驗(yàn)的軟件系統(tǒng)，比如版本的數(shù)量，參與的開發(fā)者人數(shù)，演化周期，最終選取Tomcat項(xiàng)目為實(shí)證對象展開分析。

2.1 開發(fā)者活躍度的演化

軟件需求的改變，功能的增加或刪除等，促使軟件開發(fā)和維護(hù)成為一個(gè)不斷演進(jìn)的過程，而整個(gè)過程中開發(fā)者間由于合作形成一個(gè)合作網(wǎng)絡(luò)。隨著開發(fā)者合作網(wǎng)絡(luò)的演化，開發(fā)者活躍度也在不停的改變。活躍度的改變意味著開發(fā)者在團(tuán)隊(duì)中角色地位可能也會(huì)發(fā)生改變，實(shí)時(shí)地掌控開發(fā)者的角色能有效執(zhí)行任務(wù)分配，為軟件開發(fā)與維護(hù)帶來便利。

據(jù)1.3中提到的根據(jù)rank值把活躍度劃分為3個(gè)等級：高、中、低。通過對數(shù)據(jù)的初步分析，發(fā)現(xiàn)在項(xiàng)目演化過程中，每個(gè)版本中都存在開發(fā)者的加入和離去，而且有一小部分開發(fā)者僅在某一個(gè)版本中參與合作或做出了貢獻(xiàn)。為了進(jìn)行版本間的開發(fā)者活躍度演化分析，本文提取出在這10個(gè)開發(fā)者合作網(wǎng)絡(luò)中都出現(xiàn)過的11名開發(fā)者。如果將活躍度演化趨勢相似的開發(fā)者歸為一類，則這11名開發(fā)者可整體劃分為5類，分別表示為A～E。圖2分別給出了A，B，C，D，E 5類開發(fā)者在對應(yīng)10個(gè)版本中的活躍度變化趨勢，其中橫軸表示版本序列號，縱軸表示rank值。

從圖2可發(fā)現(xiàn)：A類開發(fā)者起初一段時(shí)間非常活躍，后來變得越來越不活躍。充分體現(xiàn)為他們在前5個(gè)版本都是處于非?；钴S狀態(tài)，隨后逐漸由非?；钴S變?yōu)榛钴S，最后變?yōu)椴换钴S。B類活躍度整體上先增后減。他們的活躍度在第五個(gè)版本的時(shí)候達(dá)到最大，之后下降到最小。他們的活躍度一直處于中等偏下的狀態(tài)。C類活躍度整體下降且處于中等偏下的狀態(tài)。曲線波動(dòng)不大，活躍度偏小，整體上是下降的趨勢。D類活躍度整體下降但處于中等偏上的狀態(tài)。與C類開發(fā)者相似的是，活躍度整體都是下降的趨勢，不同的是，曲線波動(dòng)較大，活躍度偏大。E類活躍度遞增而且一直處于非?；钴S的狀態(tài)。追蹤Mark Thomas的rank值，起初為2，第6個(gè)版本已經(jīng)達(dá)到10，且隨后一直保持最大。

這5種演化趨勢呈現(xiàn)的一種可能的解釋是，在每個(gè)時(shí)間段可能分配給開發(fā)者的任務(wù)不一樣，由于開發(fā)者在不同的工作上能力大小可能也不同，導(dǎo)致活躍度的變化。當(dāng)分配給他們擅長的工作時(shí)，他們的活躍度大，當(dāng)他們做自己不擅長的工作時(shí)活躍度就會(huì)變小。為了使所選取的11名開發(fā)者的演化模式盡可能代表社區(qū)開發(fā)者的存在的演化模式，我們還考慮了那些不是在每個(gè)開發(fā)者網(wǎng)絡(luò)中都出現(xiàn)的開發(fā)者。如圖2f，可以看到這3個(gè)人分別只在軟件開發(fā)前期，中期和后期出現(xiàn)，但是他們都能歸到所提取的5類模式中。即Jean－Francois Arcand屬于第二種類型，活躍度先增后減。Johnny Kewl屬于第三種類型，活躍度慢慢減弱且處于中等偏下的狀態(tài)。Konstantin Kolinko則屬于第五種類型，活躍度呈遞增的趨勢。這樣進(jìn)一步驗(yàn)證了我們對開發(fā)者角色類型的劃分在很大程度上具有合理性，為開發(fā)者行為預(yù)測提供了一種新的視角。

圖2 5種開發(fā)者類型Fig.2 Five types of developers

2.2 活躍度與貢獻(xiàn)度的關(guān)系

研究活躍度與貢獻(xiàn)度的關(guān)系，本文用開發(fā)者提交日志數(shù)作為衡量開發(fā)者貢獻(xiàn)度的指標(biāo)，開發(fā)者提交的日志數(shù)越大說明開發(fā)者貢獻(xiàn)度越大，于是問題轉(zhuǎn)化為研究活躍度與提交日志數(shù)的關(guān)系。我們分別統(tǒng)計(jì)了每個(gè)版本中rank值為1～10的開發(fā)者的平均提交日志數(shù)。根據(jù)10個(gè)版本開發(fā)者平均提交日志數(shù)隨rank值的變化趨勢，把擁有相同變化規(guī)模的版本畫在同一個(gè)圖中，如圖3所示，橫軸代表rank值，縱軸表示平均提交日志數(shù)?？梢钥闯?0個(gè)版本中開發(fā)者的平均提交日志數(shù)隨rank值的變化都呈現(xiàn)指數(shù)增長趨勢，說明當(dāng)開發(fā)者的活躍度越大時(shí)，他提交的日志越多。一種可能的解釋為，當(dāng)一個(gè)開發(fā)者變?yōu)榛钴S時(shí)，很大程度上由于當(dāng)前任務(wù)是該開發(fā)者所擅長或熟悉的工作，以至于該開發(fā)者貢獻(xiàn)越大。反之，當(dāng)開發(fā)者的活躍度小時(shí)所做的工作可能是他不太擅長的工作。因此，我們得出兩個(gè)結(jié)論，活躍度與貢獻(xiàn)度呈指數(shù)關(guān)系，開發(fā)者活躍度的改變意味著開發(fā)者角色地位的改變。

2.3 開發(fā)者的參與程度

基于2.1節(jié)實(shí)驗(yàn)結(jié)果，我們發(fā)現(xiàn)開發(fā)者的活躍度隨時(shí)間是動(dòng)態(tài)變化的。因此，為了分析社區(qū)中不同角色演化模式下開發(fā)者從事的工作類型，有必要研究所得的5類演化模式在不同的工作類型的分布情況。研究每個(gè)開發(fā)者對不同類型工作的貢獻(xiàn)程度稱之為開發(fā)者的專業(yè)技能，挖掘出每種工作類型中專業(yè)技能最好的開發(fā)者，有助于實(shí)現(xiàn)人到項(xiàng)目的推薦或者項(xiàng)目到人的推薦。在項(xiàng)目管理過程中，掌握開發(fā)團(tuán)隊(duì)中開發(fā)者專業(yè)技能的優(yōu)劣勢對項(xiàng)目管理者而言也至關(guān)重要，通過活躍度的變化定位開發(fā)者的角色演化趨勢，預(yù)測開發(fā)者的行為便于任務(wù)分配。因此，本節(jié)重點(diǎn)對每個(gè)工作類型中5類開發(fā)者的參與程度進(jìn)行分析。

圖4中，橫坐標(biāo)代表任務(wù)信息的類型，縱坐標(biāo)代表每類開發(fā)者參與某類任務(wù)占所有這類任務(wù)的百分比。圖中A，B，C，D，E分別對應(yīng)于圖2中所劃分的5種類型。從工作類型看，不難找出每類日志中提交比例最大的開發(fā)者。簡單地說，就是可以找到每個(gè)工作類型中參與程度最好的開發(fā)者。在圖3中，提交RFE日志比例最大的是B類開發(fā)者，說明B類開發(fā)者更多從事RFE類型工作。B，C，E 3類開發(fā)者在BUG修復(fù)過程中比重均相對比較大，并且非常接近，所以，在bug分配時(shí)可以考慮優(yōu)先給這3類的開發(fā)者。尤為明顯的是，在DOC和REFAC中，B類和E類開發(fā)者比重均超過60%，說明這兩類開發(fā)者都集中從事某一類工作，且在圖2中，不難發(fā)現(xiàn)，這兩類開發(fā)者整體演化趨勢相對比較穩(wěn)定。

從開發(fā)者類型看，可以找出每類開發(fā)者提交得最多的日志類型即找出每類開發(fā)者的優(yōu)勢。例如圖4中A類開發(fā)者提交的RFE和IMPR日志所占的百分比較其他日志類型大，所以A類開發(fā)者的優(yōu)勢是做RFE和IMPR工作。分析出開發(fā)者專業(yè)技能的優(yōu)劣勢，然后根據(jù)開發(fā)者活躍度的演化趨勢來預(yù)測他的角色，以便更好地分配任務(wù)。

圖3 10個(gè)版本中開發(fā)者平均提交日志數(shù)隨rank值的變化趨勢Fig.3 The change of the average number of logs commited by developers along with the change of rank in 10versions

3 結(jié)束語

根據(jù)社區(qū)開發(fā)者的活躍度演化趨勢，文章把開發(fā)者的演化模式劃分為5種類型，每種類型開發(fā)者的活躍度表現(xiàn)出不同的變化趨勢。在分析開發(fā)者活躍度與貢獻(xiàn)度的關(guān)系時(shí)，我們發(fā)現(xiàn)開發(fā)者的活躍度與開發(fā)者所提交的日志數(shù)呈指數(shù)關(guān)系，表明交互越活躍的開發(fā)者，提供的貢獻(xiàn)也越大。因此，活躍度的改變意味著提交的日志數(shù)的改變，相反，可根據(jù)開發(fā)者提交日志的頻率來預(yù)測其角色的改變。在2.1節(jié)中，我們得到A類開發(fā)者在前5個(gè)版本中非?；钴S后來變得越來越不活躍，結(jié)合2.3節(jié)中的分析，A類開發(fā)者更擅長從事RFE和IMPR兩類工作。在實(shí)際的軟件開發(fā)過程中，在開發(fā)前期軟件對提高功能和性能方面的需求更大，而此時(shí)A類開發(fā)者占主導(dǎo)，所以在圖2a中表現(xiàn)為前5個(gè)版本A類開發(fā)者的活躍度非常大。在開發(fā)中后期，更多的時(shí)間會(huì)花費(fèi)在對軟件的測試，重構(gòu)，修復(fù)上，因此他的活躍度會(huì)慢慢下降。圖2e描述了E類開發(fā)者的活躍度逐漸變大，且隨后保持最大。在統(tǒng)計(jì)5類開發(fā)者提交的日志數(shù)時(shí)，我們發(fā)現(xiàn)E類開發(fā)者提交的日志數(shù)非常大，是其他類型開發(fā)者提交的日志數(shù)的幾倍甚至幾十倍。從圖4不難發(fā)現(xiàn)E類開發(fā)者對每類工作的貢獻(xiàn)度都不小，這也說明了他是個(gè)全能型的人才。在軟件開發(fā)的每個(gè)階段，他都是核心人物。

實(shí)驗(yàn)結(jié)果表明，在不同的項(xiàng)目版本中，根據(jù)開發(fā)者活躍度的演化趨勢，可將開發(fā)者大致劃分為5種典型的演化模式。整體上，越活躍的開發(fā)者，提交的日志數(shù)也越多，兩者呈指數(shù)增長關(guān)系。最后，對比不同演化類型的開發(fā)者在6類工作上的分布，發(fā)現(xiàn)開發(fā)者的演化趨勢與軟件開發(fā)周期有關(guān)，不同的開發(fā)者階段由于關(guān)注事項(xiàng)的不同，擅長此類事項(xiàng)的開發(fā)者開始變得活躍，而已有活躍的開發(fā)者開始受到影響，一般的開發(fā)者仍然保持穩(wěn)定的趨勢?？傊?，我們的工作發(fā)現(xiàn)開源社區(qū)中開發(fā)者的角色隨時(shí)間動(dòng)態(tài)變化，表現(xiàn)明顯的學(xué)習(xí)過程，越活躍的開發(fā)者往往貢獻(xiàn)越大，且不同類型的開發(fā)者偏好的工作事項(xiàng)也不同。

關(guān)于時(shí)效網(wǎng)絡(luò)，國內(nèi)外都備受關(guān)注，如國內(nèi)復(fù)旦大學(xué)的李翔教授團(tuán)隊(duì)，華中師范大學(xué)的池麗萍副教授團(tuán)隊(duì)，以及國外知名的巴拉巴西團(tuán)隊(duì)。時(shí)效網(wǎng)絡(luò)模型可以保留事件的時(shí)序信息，能更好地描述動(dòng)態(tài)系統(tǒng)的特征，其比例分布可以揭示不同事件之間隱藏的共性。在我們的演化分析過程中，演化本身就是一個(gè)時(shí)間序列分析，文章構(gòu)建的開發(fā)者網(wǎng)絡(luò)一定程度上就是一個(gè)在一段特定時(shí)間內(nèi)交互網(wǎng)絡(luò)，而時(shí)效網(wǎng)絡(luò)是一個(gè)更細(xì)粒度的網(wǎng)絡(luò)，關(guān)注開發(fā)者網(wǎng)絡(luò)構(gòu)建過程中的這種時(shí)間屬性，對開發(fā)者角色度量與演化分析會(huì)提供一個(gè)新的研究視角。

在已取得研究成果的基礎(chǔ)上，本文也存在一些不足之處：首先，所選取的10個(gè)版本的時(shí)間跨度并不相等，在數(shù)據(jù)上引入了一些量的偏差，導(dǎo)致版本更新時(shí)間跨度不等，但我們的實(shí)驗(yàn)結(jié)果表明，這些小的偏差并沒有影響對開發(fā)者角色演化分析，所以，文章發(fā)現(xiàn)具有一定的代表性。其次，對合作者的定義比較狹隘，我們假設(shè)歷史記錄中參與至少同一個(gè)工作線程的開發(fā)者間存在合作，沒有考慮其他形式的合作，比如論壇中的討論合作，另外，所構(gòu)建的開發(fā)者網(wǎng)絡(luò)為無權(quán)網(wǎng)絡(luò)，無法呈現(xiàn)他們之間的交互次數(shù)，但已有文獻(xiàn)中，也有很多研究者采用了類似構(gòu)建開發(fā)者網(wǎng)絡(luò)的方法，并被證實(shí)這種網(wǎng)絡(luò)的有效性。本文只分析了Tomcat軟件，把開發(fā)者歸為了5種角色類型，這樣劃分是否具有通用性，代表性，還需要對更多的開源軟件進(jìn)行實(shí)證，如Eclipse，Mozilla等流行的開源軟件。

圖4 每類日志中5類開發(fā)者提交日志所占的比例Fig.4 The proportion of logs commited by five types of developers in each type of logs

在接下來的工作中，我們將對比其他度量節(jié)點(diǎn)重要性指標(biāo)對開發(fā)者角色演化趨勢的刻畫，比如節(jié)點(diǎn)度中心性，介數(shù)中心性，特征向量中心性等，驗(yàn)證文章提取的5類開發(fā)者角色演化模式的一般性。目前時(shí)效網(wǎng)絡(luò)也備受關(guān)注，今后我們也將更細(xì)粒度地考慮合作網(wǎng)絡(luò)的時(shí)間屬性，進(jìn)一步探究角色的演化分析。另外，本文只對Tomcat軟件進(jìn)行了研究，更多來自不同開發(fā)環(huán)境，不同語言的開源軟件有待研究。

［1］ Whitehead J，Mistrík I，Grundy J，et al.Collaborative Software Engineering：Concepts and Techniques［M］.Berlin Heidelberg：Springer，2010：1－30.

［2］ Concas G，Marchesi M，Pinna S，et al.Power－Laws in a large object－oriented software system［J］.IEEE Trans On Software Engineering，2007，33（10）：687－708.

［3］ Louridas P，Spinellis D，Vlachos V.Power laws in software［J］.ACM Trans on Software Engineering and Methodology，2008，18（1）：2.

［4］ Kleinberg J.The convergence of social and technological networks［J］.Communications of the ACM，2008，51（11）：66－72.

［5］ Nakakoji K，Yamamoto Y，Kishida K，et al.Evolution patterns of open－source software systems and communities［C］／／Proceedings of the international workshop on Principles of software evolution.ACM，2002：76－85.

［6］ Xu N.An exploratory study of open source software based on public project archives［D］.Concordia University，2003.

［7］ Xu J，Gao Y，Christley S，et al.A topological analysis of the open source software development community［C］／／Proceedings of the 38th Annual Hawaii International Conference on System Sciences.IEEE，2005：4－7.

［8］ Borgatti S，Everett M.Models of Core／Periphery Structures［J］.Social Networks，2000，21（4）：375－395.

［9］ Crowston K，Howison J.Assessing the health of open source communities［J］.Computer，2006，39（5）：89－91.

［10］Sureka A，Goyal A，Rastogi A.Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis［C］／／Proceedings of the 4th India Software Engineering Conference.ACM，2011：195－204.

［11］Pinzger M，Nagappan N，Murphy B.Can developer－module networks predict failures［C］／／Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering.ACM，2008：2－12.

［12］Crowston K，Wei K，Li Q，et al.Core and periphery in free／libre and open source software team communications［C］／／Proceedings of the 39th Annual Hawaii International Conference on System Sciences.IEEE，2006，6：118.

［13］Wiggins A，Howison J，Crowston K.Social dynamics of floss team communication across channels［J］.Fourth International Conference on Open Source Software，2008，275（7）：131－142.

［14］Huang S K，Liu K M.Mining version histories to verify the learning process of legitimate peripheral participants［J］.International Conference on Software Engineering，2005，30（4）：1－5.

［15］Herzig K，Just S，Zeller A.It＇s not a bug，it＇s a feature：how misclassification impacts bug prediction［C］／／Proceedings of the 2013International Conference on Software Engineering.IEEE，2013：392－401.