ＶＣＳＴａｌｋ：基于ＤＥＡ的開源軟件開發人員效率評價工具

摘要：介紹了VCSTalk的具體設計和實現架構，并展示了它用于評價若干開源軟件項目中的開發人員效率的一個具體實例。

關鍵詞：數據包絡分析； 開源軟件； 開發人員效率評價

中圖分類號：TP31156文獻標志碼：A

文章編號：10013695(2007)04005404

0引言

開發人員效率評價即以統一的標準對一系列開發人員的效率進行評估，以評估結果表明各個開發人員的相對效率高低。該評價工作對開源軟件組織和個人很有意義。例如可以給出每個開發者的能力相對高低，有助于開源軟件組織更合理地分配資源和控制項目進度。此外，通過效率評價還可以列舉出具有相對高效率的開發者，將其作為學習對象，以幫助開源軟件開發人員提高自身能力。

對開源軟件開發人員效率進行評價存在如下困難：①開源軟件項目的過程數據往往未被集中收集管理，而是散布于各種軟件配置庫如版本控制系統和缺陷管理系統中，因此度量數據的收集比較困難。②不存在一種單一的指標可直觀地表示出效率的高低。開發人員的生產率和一些其他因素，如工作成果質量都會影響到效率高低。換言之，該評價問題具有多變量輸入/輸出特性。此外文獻[1]研究證明，對個人軟件過程能力的評價問題表現出可變規模收益特性，該證明過程同樣適用于對開發人員效率的評價。因此對開源軟件開發人員的效率評價問題也具有可變規模收益特性(即輸入和輸出具有非線性關系，VRS)。該評價問題具有非線性和多變量輸入/輸出的特點。開源項目開發人員效率評價工具需要解決數據收集的困難，如避免手工采集各個軟件配置庫中的過程數據；還必須解決問題的多變量輸入/輸出和VRS特性。

針對上述問題設計并實現的評價工具VCSTalk，兼顧了上述兩方面要求：自動地從多種軟件配置庫(如版本控制系統、缺陷管理系統等)中獲取項目數據用于執行評價工作，在解決數據收集問題的同時降低了人力開銷；基于數據包絡分析技術，既能給出量化的、直觀的評價結果，又較好地解決了多變量和VRS特性問題。為驗證其可用性，VCSTalk被應用于20個開源軟件項目中的22位開發人員，得到了客觀可靠的評價結果。

1DEA及其經典模型

Charnes A.和Cooper W.W.^[2]于1978年提出的DEA是一種用于前沿估計的非參數化數學規劃方法，適用于評價一系列決策單元(Decision Make Unit，DMU)的相對效率。DMU的效率可以看做是DMU的輸出與輸入之間的比值關系，輸入即DMU的消耗，如耗費成本的數量；輸出即DMU的產值。作為一種極限點方法，DEA將每個生產者(即DMU)與最好的生產者加以比較，從而得到生產者的相對效率。所謂最好的生產者往往是虛擬的，由若干實際生產者組成，這些相對效率高的DMU構成了效率前沿面(Efficiency Frontier)。

DEA被廣泛應用于各個領域的性能估計和評測^[3]，在軟件工程領域也同樣有應用^[4]：展示了如何使用DEA從一系列ERP項目中識別出高效率的項目。前期研究成果^[1]則給出了一種基于DEA的個人軟件過程能力評價方法，但將DEA方法在實際工具中實現用來解決實際中的問題，VCSTalk尚為首例。

從DEA方法提出至今，研究者們已經提出了多種DEA模型^{[2，3，5～7]}。VCSTalk采用了兩種經典的DEA模型，即Charnes等人提出的CCR模型^[2]以及Banker等人提出的BCC模型^[5]。CCR模型和BCC模型的對偶規劃形式如下：

CCR模型

其中，θ表示DMUj0的效率分值(Efficiency Score)，其取值范圍為0到1。效率分值為1的DMU為相對有效(Relative Efficient)；否則即為非相對有效(Relative Inefficient)。s+i(θxij0-∑nj=1xijλj)和s-k(∑nj=1ykjλj-ykj0）分別是輸入和輸出的松弛與剩余變量。松弛變量表示對輸入的過量使用，而剩余變量則表示輸出的不足。它們的數值大小表示使該DMU從非相對有效變為相對有效可作的改進及其幅度大小。在VCSTalk的評價結果中，效率分值和剩余變量是最重要的數據。通過觀察效率分值可以了解每個被評估開發人員的相對效率表現；而通過對剩余變量進行分析可以得知特定開發人員應該通過改進哪些方面來改進自身的效率。文獻[7]對CCR和BCC模型進行了更細致的討論。

2VCSTalk的設計與實現

2.1系統工作流程

VCSTalk的工作流程包括兩個主要步驟：①根據確立的效率評價指標從軟件配置庫中獲得項目數據并轉換為量化的指標值；②采用DEA模型對收集到的指標數據進行計算得到評價結果。

(1)指標選擇和數據獲取

Moser S等人^[8]研究了面向對象方法與開發人員生產效率之間的關系，他們采用功能點(FP)作為評價指標。Ying等人^[9]通過分析從CVS^[10]中導出的代碼行(Lines of Code，LOC) 和一些其他信息來理解學生在實踐課程中的開發行為，給出了一個非常好的示例說明可以從軟件配置庫中獲取哪些信息用于評價開發人員的效率。Keir等人^[11]從超過200個項目的CVS中提取出LOC和代碼質量等指標進行統計學分析，試圖找到最直觀合理的效率指標。這些研究表明LOC和開發者工作成果的質量(包括代碼質量和軟件質量)可以作為評價開發人員效率的重要指標。因此選擇了四類指標作為VCSTalk評價開發人員效率的依據(表1)。

指標名稱含義量化表示

TIME CONSUMED特定開發人員為項目投入的時間SUM(該開發人員在項目中的活躍時間段)

CODE QUANTITY特定開發人員為項目貢獻的代碼數量SUM(該開發人員增加的代碼行數)+SUM(該開發人員改的代碼行數)

CODE QUALITY特定開發人員為項目編寫的代碼質量高低CODE QUANTITY/開發人員引入項目中的違例數目

DEFECT IMMUNITY特定開發人員的代碼是否容易為項目引入BUGCODE QUANTITY/開發人員負責的BUG數目

TIME CONSUMED以小時為單位，VCSTalk從CVS的日志中獲取該指標值。由于該指標的精確性受到許多外在因素的影響，如開源軟件開發人員往往要從事其他工作，或同時參與多個軟件項目，這會帶來相當大的偏差。為了在獲取數據時盡量消除對時間估計上的偏差，VCSTalk采用了去除非活躍時間的方法。從CVS日志中可以得到開發者行為的記錄，當某開發者兩次動作的間隔長短超過某一閾值時，VCSTalk認為該開發者沒有將該時間段投入到該項目中去。該時間段即為非活躍時間。

CVS日志記錄了任意一行代碼是由哪位開發者添加到項目中來的。通過分析CVS日志能夠得到CODE QUANTITY。該指標表示為增加的代碼行數與修改的代碼行數之和。值得注意的是刪除的代碼行已經不再是項目的一部分，因而刪除的代碼行數不計入公式。

CODE QUALITY在項目中反映為開發人員編寫代碼中違例的數量多少。違例多則質量低。在這里，違例所指的是代碼中的各種缺陷，如在一行中書寫多個語句，出現定義但未被使用的變量、沒有仔細處理的異常等。這些違例可以通過對源代碼進行自動靜態分析得到。通過結合代碼分析結果和CVS日志可以得到某特定開發人員引入的違例數目。

DEFECT IMMUNITY表現為該開發人員負責的BUG數量和密度。該指標可從項目的缺陷管理系統中獲得。

上述四類指標數據的采集過程完全由程序自動進行，避免了手工收集數據的人力開銷。

(2)DEA評價計算

在數據采集階段完成之后，VCSTalk使用DEA的CCR模型和BCC模型進行計算。在計算過程中，將每個開發人員作為一個DMU，指標TIME CONSUMED作為DMU的輸入，其余三個指標作為DMU的輸出。實際計算中使用CCR和BCC的對偶規劃形式。

采用DEA模型進行計算后得到的量化結果中，θ和剩余變量對評價工作最有意義。θ為DMU(在本文的問題中指開發人員)的效率分值，效率分值為1的開發者是相對有效的，換言之就是具有較高的效率。剩余變量表示把DMU從非相對有效變成相對有效所能進行的改進及可能的改進程度。舉例來說，如果開發人員A的指標CODE QUALITY對應的剩余變量較大，則他/她應該通過提高自己的代碼質量來改進效率。

2.2系統架構與實現

如前所述，VCSTalk的工作流程是一個典型的流水線式的過程。因此VCSTalk的系統架構被設計成管道結構(圖1)：數據采集組件(DCC)、中間數據庫組件(IDB)、指標導出組件(MEC)和DEA分析其(DA)四個組件各自都將前一個組件的輸出作為自己的輸入并把自身輸出作為后續組件的輸入。控制器組件負責協同四個組件的行為來處理一個給定的效率評價任務。DCC從軟件配置庫中收集原始數據輸入到IDB中；IDB管理原始數據并響應MEC的查詢請求；MEC根據IDB提供的數據生成四種指標(第2章中定義的)的指標值并傳遞給DA。特別值得一提的是MEC通過調用代碼靜態分析工具(如PMD^[12])分析項目源代碼來獲得CODE QUALITY指標數據。DA生成最終的評價結果，其輸入和輸出均為表格形式。VCSTalk系統架構詳圖如圖2所示。

現有版本的VCSTalk實現了三種收集器對象和四種指標對象(對應四種指標)。CVSLoCCollector對象從CVS中采集代碼量信息并導入到IDB的CodeRevision對象中。CVSQoCCollector對象結合PMD作源代碼分析和CVS日志分析，得到代碼中的各種違例并導入到IDB的CodeViolation對象中。SourceForgeDefectCollector實現了一個網頁爬蟲，它從SourceForge^[13]網站上抓取特定項目的BUG信息并導入到IDB的Defect對象中。

VCSTalk的DEA分析器模塊用Mathematica^[14]開發，其余部分用Java語言實現。由于目前版本調用PMD進行代碼靜態分析，而PMD僅支持Java源文件分析，尚不能對其他語言類型的項目開發人員進行評價，可對CVSQoCController進行擴展以支持其他語言項目。VCSTalk的源代碼可從地址http://file.ttthree.com/下載。

3應用實例及結果討論

為了驗證VCSTalk的可用性和有效性，本文從SourceForge選取了20個Java語言項目。在參與這些項目的180多位開發人員中選取了22位活躍開發人員，使用VCSTalk對他們的開發效率進行評價。作為開發人員選取的標準，活躍意味著頻繁參加項目開發(從CVS日志中可以統計出參與開發的頻度)。

VCSTalk運行得到的CCR和BCC模型計算結果如表2、3所示。受篇幅所限，除效率分值和剩余變量外，其他數據均被略去，DEA計算的原始數據也未在文中給出(附于源程序包中，可從http://file.ttthree.com/下載)。

對上述結果進一步討論：

（1）在CCR模型的計算結果中，開發者5、17、19構成了效率前沿面，換言之，這三位開發者與其他開發人員相比具有較高的效率。而在BCC模型計算結果中，效率前沿面由開發者1、5、11、17、19、22構成。該計算結果的合理性可以通過對原始數據的人工分析得到驗證：開發人員5、17、19在相對短的時間內為他們所在的項目貢獻了較多的代碼且代碼中違例少，引入的BUG也相對少。開發人員22與其他開發人員相比貢獻的代碼數量少，但其代碼質量特別高且引入的BUG非常少。開發人員1和11代碼中違例數量較多但他們為項目完成的代碼量特別大，所以他們也處于效率前沿面。

（2）對于那些效率分值低于1的開發人員來說，上表中所列的剩余變量表明他們可以通過改進相應的指標來提高效率。剩余變量的數值大小表示可供改進的余地大小。表3和4中s-2和s-3分別對應CODE QUALITY指標和DEFECT IMMUNITY指標。根據兩表結果，開發人員可以知道他們應該通過改進哪些方面來提高效率以及相應可改進的幅度。

（3）VCSTalk的計算結果中各開發人員的效率分值波動較大，其根本原因在于TIME CONSUMED指標的精確程度不足，在后續研究及開發中有待改進。

4總結

對開源軟件開發人員的效率評價問題具有多變量輸入/輸出及VRS特性，且由于開源軟件的過程數據有其自身特點而較為困難。本文介紹的基于DEA方法的開源軟件開發人員效率評價工具VCSTalk在相當程度上解決了上述困難。VCSTalk提供了一種全新的開發人員效率評價方式，其優點包括：①自動數據收集機制減少了人工開銷；②考慮多種指標以及給出直觀的量化結果；③評價結果可以對開發人員改進效率提供指導。VCSTalk同樣適用于非開源軟件組織。VCSTalk所能收集到的信息越詳細則評價結果越客觀和可靠。由于商業軟件組織通常有較為規范的過程數據和嚴格定義的軟件過程，VCSTalk的應用效果會更佳。

后續的研究工作將關注以下方面：①評價結果的可視化，以可視化的形式代替目前的表格形式，使得評價結果更為直觀，便于分析。②更廣泛和細粒度的數據采集，目前VCSTalk僅引入了四項指標，更多指標的引入以及指標數據獲取的精確度提高，都有助于提高評價的質量。③評價的實時化。目前的評價是在事后進行的，實現評價的實時化，即在項目進行過程中持續地給出評價結果將有助于項目及開發人員的持續改進。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。