基于邊際貢獻的需求變更技術(shù)債務(wù)量化評估

張云潔 張 璇,2 王 旭 任峻民 唐子淇

1(云南大學(xué)軟件學(xué)院 昆明 650091)

2(云南省軟件工程重點實驗室(云南大學(xué)) 昆明 650091)

3(云南大學(xué)經(jīng)濟學(xué)院 昆明 650091)(932145749@qq.com)

在軟件生命周期中，軟件系統(tǒng)的需求會不斷變化，新的需求頻繁出現(xiàn).當(dāng)需求變更出現(xiàn)時，對于軟件系統(tǒng)的影響往往難以評估，尤其是對于較大型的軟件系統(tǒng)，很難明確需求變更可能會對整個系統(tǒng)或系統(tǒng)的一部分產(chǎn)生什么樣的影響.而如果忽略這些影響，又可能導(dǎo)致需求變更實施成本高出預(yù)期數(shù)倍.盡管需求工程對于軟件項目的成功至關(guān)重要，但大多數(shù)需求決策往往取決于開發(fā)人員的偏好和權(quán)衡，缺乏一種系統(tǒng)的、明確的管理方法.對軟件需求變更進行有效管理對軟件質(zhì)量乃至軟件項目的成功至關(guān)重要.為了衡量和評估需求變更所帶來的影響，本文引入技術(shù)債務(wù)的概念.

技術(shù)債務(wù)運用經(jīng)濟學(xué)中“債務(wù)”概念來描述“長期軟件質(zhì)量與短期利益的權(quán)衡”[1-2].當(dāng)為了實現(xiàn)項目短期利益而實施技術(shù)折中時，所欠下的技術(shù)債務(wù)從長期目標(biāo)來看，會影響軟件的質(zhì)量、成本和開發(fā)運維效率.然而，在軟件開發(fā)過程中，為了快速達到一個短期的目標(biāo)，開發(fā)者可能會暫時忽略需求變更引發(fā)的影響，正如技術(shù)債務(wù)所定義的，在沒有完全理解變更帶來的長期影響時，很可能會產(chǎn)生不必要的副作用.目前，軟件系統(tǒng)隨著業(yè)務(wù)需求的演變，不斷產(chǎn)生需求變更，研究表明，85%～90%的軟件開發(fā)預(yù)算都用于了運維階段.為了減少變更成本，盡早地管理需求變更非常重要.然而，軟件需求存在的不確定性使面向軟件需求變更進行技術(shù)債務(wù)管理更加具有挑戰(zhàn)性[3].

應(yīng)用經(jīng)濟學(xué)概念管理技術(shù)債務(wù)是一個引起學(xué)術(shù)界和工業(yè)界關(guān)注的研究課題.實物期權(quán)分析已應(yīng)用于軟件工程的多個領(lǐng)域，如軟件體系結(jié)構(gòu)[4]、設(shè)計[5]、風(fēng)險管理[6]和軟件開發(fā)方法[7].在經(jīng)濟學(xué)領(lǐng)域，邊際貢獻是指產(chǎn)品的銷售收入超過產(chǎn)品的變動成本的差額，如果產(chǎn)品不能提供邊際貢獻，通常選擇放棄生產(chǎn)這種產(chǎn)品[8].而邊際收益是指增加一個單位產(chǎn)品的銷售所增加的收益，利用邊際效益分析法有利于實現(xiàn)利潤最大化[9].將邊際貢獻和邊際收益概念運用到需求變更技術(shù)債務(wù)的管理中，可以有效輔助對需求變更的取舍決策.因此，本文研究因需求發(fā)生變更而引發(fā)的技術(shù)債務(wù)，定義需求變更技術(shù)債務(wù)，根據(jù)需求變更之間的關(guān)聯(lián)關(guān)系給出需求變更技術(shù)債務(wù)量化方法，同時采用邊際效益分析法得到需求變更的邊際貢獻值，為需求變更的實現(xiàn)順序提供依據(jù)，以協(xié)助項目組管理技術(shù)債務(wù)并且做出相應(yīng)決策.本文的主要貢獻包括：

1) 運用經(jīng)濟學(xué)中邊際貢獻的概念定義由需求變更技術(shù)債務(wù)帶來的邊際貢獻，通過分析需求變更邊際貢獻與需求變更實現(xiàn)順序的相關(guān)性，驗證了需求變更邊際貢獻概念的可用性.目前，學(xué)術(shù)界和產(chǎn)業(yè)界還沒有將邊際貢獻應(yīng)用于管理需求變更技術(shù)債務(wù)的相關(guān)研究成果.本項目組的前期工作雖然也對需求變更技術(shù)債務(wù)進行了相關(guān)研究，提出基本的需求變更技術(shù)債務(wù)概念[10]，但也未使用邊際貢獻的概念和分析方法.

2) 運用梯度提升決策樹(gradient boosting decision tree， GBDT)算法提出需求變更技術(shù)債務(wù)的邊際貢獻能力分析方法，對各個變更因素取值對其邊際貢獻影響的重要度進行排序，以確定影響邊際貢獻大小的重要因素，為需求工程師進行需求變更管理提供支持.

3) 對需求變更技術(shù)債務(wù)、需求變更關(guān)聯(lián)關(guān)系、需求變更邊際貢獻進行定義、檢測、量化和評估，提出需求變更技術(shù)債務(wù)的邊際貢獻量化評估方法，為經(jīng)濟學(xué)和需求工程相結(jié)合的軟件開發(fā)與實踐提供新思路.

1 相關(guān)工作

技術(shù)債務(wù)最普遍的特征之一是它的跨學(xué)科性質(zhì)，因為它結(jié)合了金融和軟件工程理論的要素.盡管這種性質(zhì)可能會導(dǎo)致更多的挑戰(zhàn)(由于軟件和財務(wù)觀點之間的差距)，但它可能有助于軟件工程師、架構(gòu)師、測試人員等和項目經(jīng)理之間的溝通.從業(yè)者的經(jīng)驗表明，使用基于經(jīng)濟學(xué)的術(shù)語和方法，如實物期權(quán)、成本收益分析和投資組合管理，可以彌合軟件工程師和軟件項目經(jīng)理之間的認(rèn)知差距，并有助于質(zhì)量取舍的談判，以加快產(chǎn)品交付[11].針對本文研究的需求變更技術(shù)債務(wù)，下面對該領(lǐng)域已有相關(guān)工作進行介紹.

技術(shù)債務(wù)簡潔地描述了軟件工程師在開發(fā)軟件時面臨的一個普遍問題：如何平衡短期價值與長期質(zhì)量.它的吸引力在于，一旦技術(shù)債務(wù)變得可見，工程師就可以清晰地看出債務(wù)對軟件項目有害或有益，以及債務(wù)積累和持續(xù)產(chǎn)生的利息在軟件開發(fā)過程中對系統(tǒng)質(zhì)量造成的影響[12-14].Zazworka等人[15]通過分析已有技術(shù)債務(wù)識別方法，發(fā)現(xiàn)不同的技術(shù)債務(wù)必須使用不同的識別方法.另外，Deo等人[16]研究已有技術(shù)債務(wù)方法與軟件質(zhì)量之間的關(guān)聯(lián)關(guān)系，發(fā)現(xiàn)不同的技術(shù)債務(wù)方法關(guān)注不同的軟件質(zhì)量需求，在實踐中需要明確技術(shù)債務(wù)類型.因此，在軟件項目全生命周期過程中，不同階段的技術(shù)債務(wù)也需要使用不同的方法進行識別和處理.Li等人[12]在對技術(shù)債務(wù)進行綜述研究的工作中，總結(jié)了10類軟件技術(shù)債務(wù)，其中，代碼技術(shù)債務(wù)研究最多.并且，SonarQube已成為一個成熟地用技術(shù)債務(wù)來量化代碼質(zhì)量的平臺，它可以為軟件項目組發(fā)現(xiàn)其代碼的技術(shù)債務(wù)，幫助其建立維護活動的計劃[17].相對而言，需求技術(shù)債務(wù)由于其量化困難，研究成果較少[12].在已有的相關(guān)研究工作中，Ernst等人[18-19]首先定義需求債務(wù)為最優(yōu)需求方案和實際解決需求方案之間的差距，而債務(wù)利息是這個差距的增長速率，并利用需求建模工具對變化的需求進行管理.Abad等人[20]應(yīng)用實物期權(quán)方法對軟件項目中的需求債務(wù)進行管理，且使用二項式模型和動態(tài)規(guī)劃方法探討使用實物期權(quán)方法對于需求債務(wù)評估的可行性.上述這些方法將技術(shù)債務(wù)概念引入需求工程領(lǐng)域，為后續(xù)研究工作奠定了重要基礎(chǔ)，但他們僅對單個已實現(xiàn)的需求進行分析研究，忽略了需求變更可能引發(fā)的擴散影響.針對這個問題，本項目組前期充分考慮變更影響，提出需求變更技術(shù)債務(wù)概念，并對需求變更技術(shù)債務(wù)進行了初步的量化分析[10].基于前期研究工作考慮的需求變更影響，可以得出對需求變更進行全面分析并提供有效的債務(wù)控制對于需求管理決策是一個有效的支持.但所有上述方法都缺乏對新需求變更的預(yù)測分析能力，隨著軟件系統(tǒng)需求的持續(xù)變化，當(dāng)需求發(fā)生變更時，如果只分析單個已有需求，不利于需求管理，因此，本文工作增加了對新需求變更的預(yù)測與分析，可以為需求變更管理提供更為有效的支撐.

2 需求變更邊際貢獻表示方法

在本節(jié)中我們將經(jīng)濟學(xué)中邊際貢獻的思想引入需求變更的技術(shù)債務(wù)管理中.

2.1 需求變更技術(shù)債務(wù)定義

在軟件的整個生命周期中，每當(dāng)提出一個需求變更請求時，就可能伴隨著一個需求變更技術(shù)債務(wù)的產(chǎn)生.需求變更之間必然存在的依賴關(guān)系使得需求變更管理更加困難，此依賴關(guān)系也是技術(shù)債務(wù)“利息”的來源.為了直觀地展示需求變更之間的關(guān)聯(lián)關(guān)系，使用一個有向圖來描述.在這個有向圖中，節(jié)點表示需求變更，邊表示需求變更的關(guān)聯(lián)關(guān)系，需求變更的關(guān)聯(lián)關(guān)系圖定義如下：

定義1.需求變更關(guān)聯(lián)關(guān)系圖.需求變更關(guān)聯(lián)關(guān)系圖是一個三元組G=V,E,R.其中V是節(jié)點的集合，vi∈V(i=1,2,…,m)表示一個變更需求；E是邊的集合，eij∈E(i=1,2,…,m;j=1,2,…,n)表示一個有序元素對(vi,vj),vi,vj∈V；R是一個關(guān)聯(lián)函數(shù)，它使E中的每一條邊對應(yīng)V中的一個節(jié)點，ri∈R(i=1,2,…,m)表示一個關(guān)聯(lián)關(guān)系.

需求變更技術(shù)債務(wù)的一個重要指標(biāo)就是需求變更之間的關(guān)聯(lián)關(guān)系.變更請求之間的鏈接屬性表示彼此之間的關(guān)系.以JIRA系統(tǒng)為例，鏈接屬性有10種，如表1所示.引入經(jīng)濟學(xué)中邊際貢獻概念后我們對這10種關(guān)聯(lián)關(guān)系進行研究，其中符合需求變更技術(shù)債務(wù)關(guān)聯(lián)關(guān)系可變成本類關(guān)系的關(guān)系是blocks，depends upon，requires，relates to，breaks；符合需求變更技術(shù)債務(wù)收入類關(guān)系的關(guān)系是is required by，duplicates，is duplicated by，is depended upon by，contains，is related to，incorporates.其他類型不影響對技術(shù)債務(wù)的分析，因此，不列入可變成本類和收入類關(guān)系中.

Table 1 Issue Links in JIRA

定義2.需求變更關(guān)聯(lián)關(guān)系類型.需求變更關(guān)聯(lián)關(guān)系基本類型定義為2種，分別為可變成本類變更關(guān)聯(lián)關(guān)系和收入類變更關(guān)聯(lián)關(guān)系.可變成本類變更關(guān)聯(lián)關(guān)系是指實現(xiàn)會增加其他需求變更實現(xiàn)代價的變更關(guān)聯(lián)關(guān)系.收入類變更關(guān)聯(lián)關(guān)系是指實現(xiàn)會給其他需求變更帶來收益的變更關(guān)聯(lián)關(guān)系.

在管理軟件需求變更時，很大一部分的變更管理工作是由開發(fā)者基于其個人偏好和直覺而驅(qū)使的[21].而且技術(shù)人員與用戶之間的溝通也會存在理解偏差.這種為了實現(xiàn)短期利益而忽略長期發(fā)展的需求變更所帶來的技術(shù)債務(wù)，我們將其定義為需求變更技術(shù)債務(wù).

定義3.需求變更技術(shù)債務(wù).需求變更技術(shù)債務(wù)是因快速實現(xiàn)需求變更或未實現(xiàn)需求變更而引出的花費，分為本金和利息.本金是需求變更本身的花費，利息是與該需求變更有關(guān)聯(lián)關(guān)系的其他需求變更的花費.

本文使用時間花費對需求變更的花費進行度量，時間花費為需求變更請求的解決時間與提出時間之差，即：

C=TR-TC，

(1)

其中,TR是需求變更請求的解決時間，TC是變更請求的提出時間，其中下標(biāo)R(resolved)是解決，下標(biāo)C(created)是創(chuàng)建，C(cost)是變更請求的時間花費.以變更請求HADOOP-1025為例：HADOOP-1025的提出時間為2007-02-01T02:54；解決時間為2007-02-04T05:57，則HADOOP-1025的時間花費為C=TR-TC=270 180 s.

需求變更技術(shù)債務(wù)的量化分為2部分，包括本金的量化及利息的量化.需求變更技術(shù)債務(wù)為

(2)

其中，D(debt)表示需求變更技術(shù)債務(wù)總值.C是需求變更的時間花費，cij是第i層(1≤i≤m)第j個(1≤j≤n)需求變更技術(shù)債務(wù)的利息，i和j分別是以該需求變更為原點和該需求變更具有第i級關(guān)系的第j個需求變更.CP則表示需求變更技術(shù)債務(wù)的本金，下標(biāo)P(principal)表示本金.根據(jù)需求變更關(guān)聯(lián)關(guān)系圖,系數(shù)li表示與該需求變更關(guān)聯(lián)的需求變更數(shù)的倒數(shù)，li用來表示關(guān)系的關(guān)聯(lián)強度，li越小，這個需求變更的關(guān)系越復(fù)雜.系數(shù)rx(x≥1,整數(shù))表示不同的依賴關(guān)系類型，可變成本類需求變更關(guān)聯(lián)關(guān)系和收入類需求變更關(guān)聯(lián)關(guān)系的系數(shù)值為1，其他關(guān)聯(lián)關(guān)系系數(shù)值為0.

在前面的需求變更技術(shù)債務(wù)的量化過程中，我們得到了每一個需求變更技術(shù)債務(wù)的債務(wù)值，接下來，我們把需求變更項目的貢獻定義為需求變更的邊際貢獻：

定義4.需求變更邊際貢獻.需求變更邊際貢獻是指需求變更對項目的貢獻力，分為銷售收入和可變成本2個部分.銷售收入指的是與該需求變更具有收入類關(guān)聯(lián)關(guān)系的需求變更債務(wù)值之和.可變成本指的是與該需求變更具有可變成本類的需求變更債務(wù)值之和.需求變更邊際貢獻值等于銷售收入減去可變成本，即：

(3)

其中，M(marginal)表示需求變更的邊際貢獻率，Di表示與這個需求變更技術(shù)債務(wù)具有變更關(guān)聯(lián)關(guān)系的需求變更的債務(wù)值，a表示需求變更之間的變更關(guān)聯(lián)關(guān)系為收入類變更關(guān)聯(lián)關(guān)系，設(shè)a=1，p表示需求變更之間的變更關(guān)聯(lián)關(guān)系為可變成本類變更關(guān)聯(lián)關(guān)系，設(shè)p=-1.

在經(jīng)濟學(xué)中，邊際效益是指以最低的成本使經(jīng)濟利潤最大化，從而達到帕累托最優(yōu).指與前一單位相比，后一單位物品或勞務(wù)的效用.如果后一單位的效用大于前一單位的效用，則邊際效用遞增，反之，邊際效用遞減.在會計中，邊際效益是指以銷售收入減去變動成本后的余額，以邊際貢獻為指標(biāo).邊際貢獻也是基于損益分析原理的產(chǎn)品生產(chǎn)決策的重要指標(biāo).

需求變更本身的債務(wù)值可以看作是該需求變更的固定成本.在需求變更的償還過程中，一定量的具有變更關(guān)聯(lián)關(guān)系的需求變更的邊際貢獻(也就是銷售收入減去可變成本后的結(jié)果)首先是用來彌補需求變更的固定成本總額，在彌補了需求變更的所有固定成本后，如有多余，才能構(gòu)成利潤.這就有可能出現(xiàn)3種情況：

1) 當(dāng)被償還的需求變更的邊際貢獻等于所發(fā)生的固定成本總額時，只能保本，即做到不盈不虧.

2) 當(dāng)被償還的需求變更的邊際貢獻小于所發(fā)生的固定成本總額時，就要發(fā)生虧損.

3) 當(dāng)被償還的需求變更的邊際貢獻大于所發(fā)生的固定成本總額時，將會盈利.

因此，需求變更邊際貢獻的實質(zhì)所反映的就是該需求變更為軟件項目所能作出的貢獻大小，只有當(dāng)需求變更的貢獻能力達到一定的數(shù)量后，該需求變更的處理所帶來的邊際貢獻才有可能彌補其本身的技術(shù)債務(wù)，為軟件系統(tǒng)的質(zhì)量提升帶來盈利.

在實際項目中，實現(xiàn)成本過于高且毫無實現(xiàn)價值的需求變更的技術(shù)債務(wù)償還會被慎重考慮.因此，經(jīng)過反復(fù)驗證分析，我們設(shè)置臨界參數(shù)，為該需求變更的邊際貢獻值與其固定成本即該需求變更本身債務(wù)值做比較.我們把這個臨界值定義為需求變更參考系數(shù).

定義5.需求變更參考系數(shù).需求變更參考系數(shù)指的是需求變更的技術(shù)債務(wù)是否值得被償還的判斷參數(shù).

形式化計算為

J=M-D,

(4)

其中,J表示判斷參數(shù)，D表示債務(wù)值也就是固定成本，M表示邊際收益.若J<0,表明需求變更邊際貢獻小于其自身的固定成本，則慎重考慮該需求變更；若J>0或J=0,表明需求變更邊際貢獻大于其自身的固定成本，則根據(jù)需更變更邊際貢獻順序表做順序處理.

2.2 需求變更邊際貢獻量化評估

需求變更邊際貢獻的量化評估使用如圖1所示的5個步驟：

Fig. 1 Quantitative evaluation process of marginal benefit for requirement changes

步驟1. 從項目中收集歷史需求變更數(shù)據(jù)，需求變更用vi∈V，i=1,2,…,n表示，根據(jù)2.1節(jié)中需求變更基本類型的定義，將需求變更關(guān)聯(lián)關(guān)系分為2種基本類型.可變成本類變更關(guān)聯(lián)關(guān)系在需求變更的關(guān)聯(lián)關(guān)系圖中定義為元素對(vi,vj)的關(guān)聯(lián)關(guān)系rk=cost(其中：i=1,2,…,m;j=1,2,…,n;k=1,2,…,n)；收入類變更關(guān)聯(lián)關(guān)系在需求變更的關(guān)聯(lián)關(guān)系圖中定義為元素對(vi,vj)的關(guān)聯(lián)關(guān)系rk=income(其中：i=1,2,…,n;j=1,2,…,n;k=1,2,…,n).

步驟2. 基于收集的數(shù)據(jù)進行篩選，并構(gòu)建需求變更的關(guān)聯(lián)關(guān)系圖，圖2給出一個Hadoop項目需求變更關(guān)聯(lián)關(guān)系圖的示例.

Fig. 2 Requirements change relationship model

2011年5月27日，名為dhruba borthakur的用戶提交了需求變更的類型為改進的需求變更HDFS-2006，要求HDFS可以提供文件存儲的擴展屬性，但是開發(fā)人員并沒有對其進行評估和處理，導(dǎo)致產(chǎn)生一系列bug(即HADOOP-11286，ACCUMULO-3100等)，接下來，越來越多與其相關(guān)的需求變更被提出，最后，部分關(guān)聯(lián)關(guān)系圖如圖2所示，其中，突出顯示了3個具有可變成本類變更關(guān)聯(lián)關(guān)系的節(jié)點，其他節(jié)點關(guān)系類似.

步驟3.計算需求變更技術(shù)債務(wù)值，包括本金和利息2個部分.例如：圖2中變更請求HADOOP-10150的債務(wù)計算為

所有Hadoop項目需求變更技術(shù)債務(wù)計算后，結(jié)果排名前10的變更如表2所示.

表2給出了排名前10的需求變更技術(shù)債務(wù)值，對于債務(wù)值較大的需求變更，如HDOOP-8744，往往意味著其與其他需求變更之間的關(guān)聯(lián)關(guān)系比較復(fù)雜，所以在償還時需要考慮多方面因素.接下來，利用需求變更技術(shù)債務(wù)值的結(jié)果繼續(xù)進行下一步需求變更邊際貢獻值的計算，對我們進行需求變更償還決策提供參考.

Table 2 Hadoop Requirement Changes’ Technical Debt

步驟4.在上述需求變更技術(shù)債務(wù)的量化過程中，我們得到了每一個需求變更技術(shù)債務(wù)的債務(wù)值，根據(jù)定義4我們將一個需求變更具有可變成本類變更關(guān)聯(lián)關(guān)系的需求變更債務(wù)值之和看作該需求變更的可變成本；將一個需求變更具有收入類變更關(guān)聯(lián)關(guān)系的需求變更債務(wù)值之和看作該需求變更的銷售收入.

例如變更請求HADOOP-9671的邊際貢獻值為

M(HADDOP-9671)=(235 693+3 154 727.5+225 976)-(617 499+4 672)=5 194 225.5 s.

與需求變更HADOOP-9671具有可變成本類關(guān)聯(lián)關(guān)系的需求變更為HADOOP-2856(D=617 499 s)、HADOOP-4685(D=4 672 s)；與需求變更HADOOP-9671具有收入類關(guān)聯(lián)關(guān)系的需求變更為HADOOP-9392(D=2 435 693 s)、HADOOP-8779(D=3 154 727.5 s)、HADOOP-9533(D=225 976 s).根據(jù)式(3)，用與該需求變更具有收入類關(guān)聯(lián)關(guān)系的需求變更債務(wù)值之和減去與該需求變更具有可變成本類的需求變更債務(wù)值之和就可以得到需求變更HADOOP-9671的邊際貢獻.將得到的每一個需求變更的邊際貢獻由大到小順序排列得到需求變更邊際貢獻順序表.對于不存在變更關(guān)聯(lián)關(guān)系的需求變更，對于其債務(wù)值的償還，可以根據(jù)需要隨時處理，所以不需要計算邊際貢獻值為實現(xiàn)順序做決策.對于具有其他變更關(guān)聯(lián)關(guān)系的需求變更，可按需求變更邊際貢獻順序表順序處理.

Hadoop項目中需求變更邊際貢獻計算結(jié)果排名前10如表3所示：

Table 3 Hadoop Marginal Contribution for Requirement Changes

得到邊際貢獻結(jié)果排序表后，可以把排序表的順序作為需求變更實現(xiàn)順序的參考.例如：表3中需求變更邊際貢獻值最大的為需求變更HADOOP-8065，其邊際貢獻值8 435 551.75，那么在我們考慮需求變更債務(wù)值的償還時，應(yīng)該對其優(yōu)先考慮，以達到最大收益、最小成本的目的.

參照需求變更的邊際貢獻值對變更優(yōu)先級進行排序意味著邊際貢獻值應(yīng)與變更優(yōu)先級具有相關(guān)性，下面我們用皮爾遜相關(guān)系數(shù)分析需求變更邊際貢獻與需求變更實現(xiàn)的時間相關(guān)性，以驗證需求變更邊際貢獻排序表的可用性.使用皮爾遜相關(guān)系數(shù)計算為

其中，M為需求變更邊際貢獻，t為需求變更實現(xiàn)時間.

我們對Hadoop項目進行相關(guān)性計算，相關(guān)系數(shù)結(jié)果為0.912，表明需求變更邊際貢獻與需求變更實現(xiàn)順序具有強關(guān)聯(lián)關(guān)系，即：運用需求變更邊際貢獻為需求變更提供決策支持具有一定的參考價值.

步驟5. 需求變更參考系數(shù)J值計算.利用定義5和式(4)，對需求變更進行參考系數(shù)計算，結(jié)合需求變更邊際貢獻的量化結(jié)果，得到需求變更參考系數(shù)J值表，給出需求變更優(yōu)先級.例如：Hadoop項目中需求變更J值(J<0)部分計算結(jié)果如表4所示：

Table 4 J Values for Hadoop Requirement Changes

以表4中變更請求HADOOP-8065為例，變更請求HADOOP-8065是一個改進類型的變更請求，它希望可以提供一個密鑰用于檢索托肯認(rèn)證實體和Hadoop服務(wù)的密鑰或證書，主要包括：定義密鑰提供API，以查詢具有特定實體名稱的密鑰證書；定義并實現(xiàn)相關(guān)實體用于實現(xiàn)密鑰提供的插件；基于本地密鑰存儲文件實現(xiàn)簡單密鑰提供程序.由表4可知，HADOOP-8065的J值為負(fù)且最小，所以HADOOP-8065為項目所帶來的貢獻不大，卻會耗費大量的成本，由此可知，HADOOP-8065的處理是否償還其債務(wù)值是需要開發(fā)人員慎重考慮的.而在實際情況中，HADOOP-8065的提出時間是2013年8月5日，這個變更請求截至2018年2月23日都沒有被處理.

另外，Hadoop項目中需求變更J值(J>0)部分計算結(jié)果如表5所示.

表5中需求變更的J值均大于0，這些需求變更為盈利類，對于此類需求變更，可以依據(jù)需求變更邊際貢獻排序表的先后順序依次處理.

Table 5 J Values for Hadoop Requirement Changes

3 需求變更邊際貢獻預(yù)測

本節(jié)的研究目的是構(gòu)建一個能夠預(yù)測需求變更邊際貢獻能力的預(yù)測模型.首先，定義預(yù)測指標(biāo)，選取適當(dāng)?shù)念A(yù)測方法和預(yù)測指標(biāo)介紹預(yù)測模型的綜合性能評價指標(biāo);接下來，介紹特征相對重要度的計算方法.

3.1 定義預(yù)測指標(biāo)

對于一些未解決的需求變更，其解決時間用實驗時的時間來衡量，方法較為簡單，而沒有解決時間的情況，應(yīng)該用預(yù)測方法預(yù)測更為合適.因此，下面我們采用科學(xué)的預(yù)測方法來分析未解決需求變更的邊際貢獻能力.在構(gòu)建預(yù)測模型時，我們通過選擇以下能夠衡量需求變化邊際貢獻的特征來定義預(yù)測指標(biāo)：

1) 指標(biāo)能夠反映需求變更解決時間的特征；

2) 指標(biāo)能夠反映需求變更邊際貢獻隨著時間不斷變化的特征.

在本項目的早期階段我們發(fā)現(xiàn)：變更請求報告的重要程度可以使用變更請求報告本身的一些指標(biāo)進行預(yù)測.受缺陷預(yù)測、需求易變性、缺陷報告質(zhì)量、缺陷優(yōu)先級排序的相關(guān)研究啟發(fā)[21]，我們定義了在JIRA跟蹤系統(tǒng)中能夠衡量變更請求報告的4個指標(biāo)：需求變更的需求變更類型(issue type)、需求變更狀態(tài)(status)、需求變更的重要性(priority)、需求變更的解決方式(resolution)等類別特征能夠衡量至今未解決的需求變更即將花費的解決時間的指標(biāo).如表6所示：

Table 6 Prediction Indicators

受本項目前期工作[21]的啟發(fā)，發(fā)現(xiàn)除了變更請求報告的提出時間、解決時間等指標(biāo)可以直觀地影響需求變更的時間花費以外，變更請求報告的一些其他指標(biāo)對時間花費也會有一定的影響，從而進一步影響到需求變更的邊際貢獻能力大小，由此可見，選用這些指標(biāo)來構(gòu)建需求變更貢獻能力的預(yù)測模型是可行的.

3.2 預(yù)測方法和預(yù)測指標(biāo)選擇

本文的研究目的是建立一個未償還的需求變更的邊際貢獻能力預(yù)測模型.我們選擇梯度提升決策樹作為構(gòu)建預(yù)測模型的方法.GBDT分類問題的決策樹是二叉分類樹，回歸問題的決策樹是二叉決策樹，我們這里使用的是二叉分類樹.GBDT與Adaboost最主要的區(qū)別在于兩者如何識別模型的問題.Adaboost基于錯分?jǐn)?shù)據(jù)點對問題進行識別，通過改變錯分?jǐn)?shù)據(jù)點權(quán)重值對模型進行改進.GBDT通過負(fù)梯度來識別問題，通過計算負(fù)梯度來改進模型.在本文中以Spring Framework項目為研究案例，分析其JIRA系統(tǒng)需求變更跟蹤管理數(shù)據(jù)，將需求變更的需求變更類型(issue type)、需求變更狀態(tài)(status)、需求變更的重要性(priority)、需求變更的解決方式(resolution)等屬性的取值作為特征值，將需求變更的邊際貢獻值分為貢獻能力大、貢獻能力小2類作為其標(biāo)簽.構(gòu)建其訓(xùn)練數(shù)據(jù)集，以預(yù)測需求變更的貢獻能力.本文選擇分類回歸樹(classification and regression tree， CART)作為基學(xué)習(xí)器：GBDT預(yù)測模型提供需求變更貢獻能力大小的分類預(yù)測.因此需要確定一個點來確定需求變更邊際貢獻能力的大小，貢獻能力大的預(yù)測為強，貢獻能力小的預(yù)測為弱.在我們的研究中，設(shè)置GBDT預(yù)測模型的分類點為一般數(shù)學(xué)中通常選取的中位數(shù).我們把需求變更邊際貢獻值大于需求變更邊際貢獻值序列中位數(shù)的分類為強；把需求變更邊際貢獻值小于需求變更邊際貢獻值序列中位數(shù)的分類為弱.

3.3 預(yù)測模型性能綜合評價指標(biāo)

為了評估預(yù)測模型的性能，本文使用曲線下面積(area under the curve，AUC)和查全率(recall)這2個指標(biāo)來評價模型的性能.AUC是需求變更邊際貢獻能力被正確預(yù)測的數(shù)目大于被錯誤預(yù)測的數(shù)目的概率，AUC越大表示模型區(qū)分正例和負(fù)例的能力越強.查全率又稱為召回率，是需求變更貢獻能力被正確預(yù)測為能力大的數(shù)目與總的實際為能力大的數(shù)目的比值.

3.4 預(yù)測模型工具

本文用Python語言開發(fā)了一套需求變更邊際貢獻分析工具以幫助軟件項目管理需求變更，提高軟件質(zhì)量，減少開發(fā)成本.工具的預(yù)測模型流程圖如圖3所示:

Fig. 3 Flow chart of prediction model

利用需求變更貢獻能力分析工具，我們先從變更請求報告中獲得數(shù)據(jù)，再對數(shù)據(jù)進行預(yù)處理來得到關(guān)系圖，然后進行度量指標(biāo)的計算，同時得到需求變更邊際貢獻排序表和需求變更邊際貢獻值排序表.最后，定義預(yù)測指標(biāo)，選擇預(yù)測方法，以及預(yù)測模型性能的評價指標(biāo)，進行需求變更邊際貢獻能力預(yù)測，根據(jù)評價指標(biāo)驗證預(yù)測模型的可用性.

4 案例研究

本節(jié)以Spring Framework項目為研究案例，下面主要介紹案例數(shù)據(jù)的收集處理、需求變更邊際貢獻的指標(biāo)計算、 需求變更邊際貢獻分析的實驗過程和實驗結(jié)果的分析.

4.1 數(shù)據(jù)收集與處理

本文分析研究變更請求追蹤系統(tǒng)上的變更請求報告，用時5天，總共收集了Spring Framework項目20 000條變更請求報告，最終我們將收集的20 000條需求變更存入文件中，因為本文的研究涉及到需求變更的提出時間、解決時間、需求變更之間的關(guān)聯(lián)關(guān)系、需求變更的需求變更類型(issue type)、需求變更狀態(tài)(status)、需求變更的重要性(priority)、需求變更的解決方式(resolution)等屬性.

在計算過程中，我們主要以具有需求變更關(guān)聯(lián)關(guān)系的需求變更作為研究對象，所以從收集的20 000條變更請求報告中篩選出具有關(guān)聯(lián)關(guān)系的6 000條需求變更進行下一步研究.我們將收集到的數(shù)據(jù)存入表格中，提取出計算本金所需要的提出時間、解決時間，方便后續(xù)實驗對本金進行計算.數(shù)據(jù)存儲如圖4所示：

Fig. 4 Data storage

Fig. 5 Partial screenshots of calculation results

圖4中的中括號表示此單元格為空，也就是該需求變更與其他需求變更不具有此項關(guān)聯(lián)關(guān)系.其中序號2記錄中的SPR-927表示SPR-926與SPR-927之間的需求變更關(guān)聯(lián)關(guān)系為is duplicated by.

本文對JIRA中的10種關(guān)聯(lián)關(guān)系進行了研究以建立需求變更關(guān)聯(lián)關(guān)系數(shù)據(jù)集.其中符合需求變更技術(shù)債務(wù)關(guān)聯(lián)關(guān)系可變成本類關(guān)系的關(guān)系是blocks，depends upon，requires，relates to，breaks；符合需求變更技術(shù)債務(wù)收入類關(guān)系的關(guān)系是is depended upon by，duplicates， is related to， is duplicated by，contains， is required by， incorporates.其他類型的關(guān)聯(lián)關(guān)系出現(xiàn)較少，對整個軟件項目的影響可以忽略不計，所以不納入可變成本類和收入類變更關(guān)聯(lián)關(guān)系中，作“不存在需求變更關(guān)聯(lián)關(guān)系”處理.

4.2 需求變更邊際貢獻計算

根據(jù)第2節(jié)的量化方法及步驟，需求變更邊際貢獻計算部分結(jié)果如圖5所示:

在圖5中，第1列表示序號，Created列表示需求變更的提出時間，Resolved列表示需求變更的解決時間，capital列表示需求變更的本金，interest列表示需求變更的技術(shù)債務(wù)值，boundary列表示需求變更邊際貢獻值，T列表示需求變更邊際效應(yīng)參考系數(shù)值計算結(jié)果.

4.3 需求變更邊際貢獻分析結(jié)果

1) 需求變更邊際貢獻值計算結(jié)果分析

由第2節(jié)對邊際貢獻的皮爾遜相關(guān)性分析可知，需求變更的實現(xiàn)順序與需求變更的邊際貢獻值強相關(guān).那么對于具有其他變更關(guān)聯(lián)關(guān)系的需求變更，可按需求變更邊際貢獻順序表順序處理；對于不存在變更關(guān)聯(lián)關(guān)系的需求變更，其債務(wù)值的償還可以根據(jù)需要隨時處理.需求變更邊際貢獻計算結(jié)果排名前10如表7所示：

Table 7 Marginal Contribution of Requirement Changes

如表7所示，第1列為排名；第2列表示需求變更的編號；第3列表示需求變更邊際貢獻值.在需求變更邊際貢獻排序表排名第一的為需求變更SPR-11399，名為“Improve documentation of transactional support in the TestContext framework”.從現(xiàn)狀來看，因為SpringTestContext框架中事務(wù)支持參考手冊中的文檔目前非常缺乏，目前只有2個示例:一個示例是虛構(gòu)的TransactionalTest，它是一個基于JUnit的POJO測試類，它演示了與SpringTest-Context框架中事務(wù)相關(guān)的所有注釋的用法，但不太具有代表性.另一個示例為AbstractClinicTests，它是Abstract Transactional JUnit4 Spring Context Tests的擴展，它演示了CountRowInTable()的使用.因此，盡管參考手冊中有2個示例，但這2個示例都沒有展示出最佳的實踐或典型的使用場景.此外，使用TestNG的例子為零.所以提出該需求變更要求：

① 刪除AbstractClinicTests示例，并在“事務(wù)管理”或“JUnit支持類”中創(chuàng)建類似的基于JUnit的示例.

② 將“PetClinic Example”的內(nèi)容重新調(diào)整為新的“最佳實踐”部分.

③ 創(chuàng)建1個基于測試的示例，類似于新的基于JUnit的示例，以便于比較.

④ 增加與SPR-11397討論相關(guān)的測試內(nèi)容.

⑤ 在SPR-6132中添加與討論相關(guān)的測試內(nèi)容.

該需求變更報告頁面如圖6所示.因為該需求變更與SPR-11397，SPR-6132都有相關(guān)性，實現(xiàn)了該需求變更也有益于需求變更SPR-11397，SPR-6132，對于這樣的需求變更，我們可以考慮優(yōu)先實現(xiàn).

2) 需求變更參考系數(shù)分析

對于需求變更參考系數(shù)小于0的需求變更，一般意味著其對整個軟件的貢獻非常有限，卻又花銷巨大，在對需求變更實現(xiàn)進行決策時往往需要慎重考慮.需求變更參考系數(shù)排序后10位如表8所示：

Table 8 Requirements Change References

分析需求變更參考系數(shù)排序表最后1個需求變更SPR-5120，SPR-5120的提出時間為2019年8月29日，由Pedro Santo在Spring Framework變更請求追蹤系統(tǒng)中提交，標(biāo)題為Spring component scanning does not work within JBoss EJB container，其報告頁面如圖7所示.該需求變更是一個Improvement類型的需求變更，當(dāng)提出者從一個JBoss管理的EJB中創(chuàng)建ApplicationContext時，spring檢測功能失效，作者在不同的環(huán)境中測試spring組件，只有在JBoss管理的EJB中失效.該需求變更與多個需求變更都存在關(guān)聯(lián)關(guān)系，如圖8所示.在對需求邊更SPR-5120進行處理時，需求同時考慮與其相關(guān)聯(lián)的多個需求變更，需求變更SPR-5120是否償還其債務(wù)值，也會對其他與之關(guān)聯(lián)的需求變更債務(wù)值償還決策產(chǎn)生影響，關(guān)聯(lián)的需求變更越多，受到影響的需求變更也就越多，所以需要對其慎重考慮.

Fig. 6 Requirement change SPR-11397 report page

Fig. 7 Requirement change SPR-5120 report page

Fig. 8 Requirement change SPR-5120 association diagram

4.4 需求變更邊際貢獻能力分析實驗

我們將需求變更屬性和需求變更邊際貢獻值記錄合并以后產(chǎn)生了4 828條可用數(shù)據(jù)，分析需求變更報告的所有屬性，篩選出需求變更的需求變更類型(issue type)、需求變更狀態(tài)(status)、需求變更的重要性(priority)、需求變更的解決方式(resolution)等類別特征，方便進行處理，部分結(jié)果如圖9所示.

我們將需求變更邊際貢獻值分為2類，即貢獻能力大、貢獻能力小.再以5∶5的比例將4 828條可用記錄分別作為訓(xùn)練集和測試集.然后我們對需求變更貢獻能力的特征值進行度熱編碼.主要結(jié)果如圖10所示.

Fig. 9 Partial screenshots of eigenvalue screening results

Fig. 10 Partial screenshots of one-hot coding results

梯度提升算法(GDBT)需要對一些重要參數(shù)進行設(shè)置，例如：每一輪的迭代步長v、樹的最大深度MathDepth、損失函數(shù)L、模型的迭代次數(shù)N.每輪的迭代步長v=0.001；損失函數(shù)L設(shè)為均方差；接下來，在60～1 200的區(qū)間內(nèi)尋找最佳迭代次數(shù)，由于平均絕對誤差的最大值和最小值僅相差0.005 6，因此選擇對應(yīng)于最小平均絕對誤差的迭代次數(shù)作為最佳值，即300作為迭代次數(shù)；然后調(diào)整樹的最大深度MathDepth.隨著樹的最大深度增加，平均絕對誤差波動，但平均絕對誤差最大值和最小值之間的差值僅為0.013 15，因此基于均方根誤差選擇最佳MathDepth，均方根誤差最小值0.172 8對應(yīng)于樹深度為9.

4.5 需求變更邊際貢獻預(yù)測結(jié)果分析

Spring Framework項目使用該預(yù)測模型的曲線下面積AUC結(jié)果如圖11所示.本文提供了預(yù)測需求變更邊際貢獻能力的框架，根據(jù)得到的AUC=0.754 6,表明需求變更邊際貢獻能力被正確預(yù)測的數(shù)目大于被錯誤預(yù)測的數(shù)目的概率為75%及以上.另外，得到如表8的混淆矩陣表示的實驗結(jié)果.

Fig. 11 Area under curve

Table 8 Predictive Experimental Results

實驗結(jié)果表明， Spring Framework項目使用該預(yù)測模型的召回率為87%及以上，表明需求變更貢獻能力被正確預(yù)測為能力大的數(shù)目與總的實際為能力大的數(shù)目的比值為87%及以上.在構(gòu)建預(yù)測模型時，我們使用這4個預(yù)測變量：需求變更的需求變更類型(issue type)、需求變更狀態(tài)(status)、需求變更的重要性(priority)、需求變更的解決方式(resolution).預(yù)測模型計算得到的查全率越高，則表明需求變更貢獻能力的預(yù)測的準(zhǔn)確度也越高.結(jié)果表明本文提出的預(yù)測方法具有一定的可用性.

Fig. 12 Importance ranking results

最后，我們對預(yù)測模型的特征值指標(biāo)對需求變更貢獻能力大小影響做了重要度排序，結(jié)果如圖12所示.由圖12可以看出，Resolution_Complete，Resolution_Duplicate，Resolution_Fixed這3個特征值對需求變更的貢獻能力大小影響較大，分別為：0.238，0.225，0.173.解決方式Complete，Duplicate，F(xiàn)ixed分別表示完成、復(fù)制、已修復(fù).從含義上看，已經(jīng)完成、復(fù)制和已修復(fù)這3種解決方式是已經(jīng)解決了的需求變更，所以不會帶來太大的技術(shù)債務(wù)，所以貢獻重要度排序較高.Issue Type_Improvement和Issue Type_New Feature對應(yīng)的重要度分別為0.038和0.037.這2個特征值對于需求變更的貢獻能力大小也有一定的影響，這2個特征值分別表示需求變更類型為改進和新功能.改進一般指針對當(dāng)前系統(tǒng)的某個功能進行改進，通常不與其他的需求變更產(chǎn)生很復(fù)雜的關(guān)聯(lián)關(guān)系，不會帶來太大的技術(shù)債務(wù).而新功能一般是指為系統(tǒng)增加1個新功能，改進和新功能這2個Issue類型都屬于對系統(tǒng)的完善，雖然會產(chǎn)生一定的工作量，但是對于整個系統(tǒng)是有益的，所以能夠?qū)π枨笞兏暙I能力大小產(chǎn)生一定影響.因此，在我們衡量需求變更貢獻能力時，遇到這些關(guān)鍵特征值時，對需求變更貢獻能力可以稍作樂觀估計.

5 總結(jié)和展望

本文根據(jù)需求變更所產(chǎn)生的2種方式定義了需求變更技術(shù)債務(wù)，再引進經(jīng)濟學(xué)中“邊際貢獻”的概念，將需求變更跟蹤系統(tǒng)中篩選出的10類需求變更之間的關(guān)聯(lián)關(guān)系根據(jù)邊際貢獻要素給出關(guān)聯(lián)關(guān)系的不同分類，將需求變更中的各種重要參數(shù)與邊際貢獻的各類要素一一對應(yīng)，以便使用邊際貢獻分析法分析需求變更并且應(yīng)用到大型開源項目Spring Framework中，通過實驗驗證了需求變更邊際貢獻概念的可用性和技術(shù)的可行性.之后，運用GDBT算法對Spring Framework中的需求變更歷史記錄進行研究，提出了一種需求變更的邊際貢獻能力分析方法，并且對各個字段取值對其邊際貢獻影響的重要度進行排序.結(jié)果表明，該分析方法可以為需求工程師衡量其工作量和風(fēng)險提供有價值的結(jié)果.

目前，需求變更邊際貢獻分析方法僅應(yīng)用于Spring Framework項目，還有很多不同的軟件項目沒有覆蓋.另外，Spring Framework項目采用敏捷開發(fā)方法，和傳統(tǒng)過程模型相比，可能會有不同.下一步的工作將探索如何將本文提出的方法應(yīng)用到其他開源軟件項目中或一些基于傳統(tǒng)過程模型開發(fā)的軟件項目中，進一步驗證量化方法的效果.此外，本文的技術(shù)債務(wù)研究僅基于時間來進行需求變更技術(shù)債務(wù)的量化，而技術(shù)債務(wù)也涉及到項目代碼、項目維護等，僅根據(jù)時間研究需求變更技術(shù)債務(wù)不夠全面，下一步將嘗試融合其他相關(guān)可量化指標(biāo)，對多種技術(shù)債務(wù)量化方法的融合進行研究.