金融開源軟件成熟度的可變權重模型和改進方法

蔡一曉 吳承榮

(復旦大學計算機科學技術學院 上海 200433)

0 引 言

隨著開源軟件行業的不斷成熟和完善，地位越來越高，很多公司考慮在自己的系統中使用特定的開源軟件，而在市場中往往存在幾款從功能等方面比較接近的開源軟件，需要一套比較完整的評測流程來幫助使用者決定具體使用哪一款開源軟件。

現在通用的包括OMM、國家軟件質量評估標準等軟件成熟度評估體系考慮了軟件的一部分具體的評測標準。在這一個基礎上再結合金融行業的具體需求，就可以建立一套比較完善的軟件成熟度評估體系。

為了全面評價金融行業開源軟件的質量及其應用的成熟度，幫助軟件需求方從眾多開源軟件中選擇合適的軟件，金融行業開源軟件成熟度評測體系將圍繞金融業務的實際需求，對開源軟件的選型、質量檢測、成熟度評估以及軟件供應商的評測等進行全方位的評估。

在金融行業開源軟件成熟度評估體系中我們已經建立了比較詳盡的評測條目，在已有具體的評測條目的基礎上，本文將根據已經采集到的數據來量化評估金融行業開源軟件的具體特性，建立具體的數學模型將采集到的數據客觀化。

同時，本文也將討論這些數據的采集方法，做到將現在的金融開源軟件的評測模型運用到實際的評測流程當中去，使得企業可以使用我們的模型和方法來判斷在具體的環境中應該選擇哪一款開源軟件。

1 金融開源軟件成熟度整體模型

1.1 整體模型的流程和方法

一個完整的評測一款開源軟件的流程包括建立配套的測評環境、定義具體的評估流程、質量屬性和評分標準。屬性評測取得相對應的值，以及根據具體的模型來計算結果。圖1是軟件成熟度測試的大致流程。

圖1 開源軟件成熟度評測的流程

在確定了具體的軟件類別之后，需要我們考慮的是如何去定義評估流程，設定具體的評估條件。評估條件是指軟件在成熟度評估中某一方面的具體特征，它反映該軟件在這一評估點上表現的好壞程度，對所有評估條件的綜合考慮即得到軟件成熟度的評價值。

評估條件是建立一個評測模型的基礎，評估條件選取得是否合適、得當，對整個評估結果的準確性、公正性會造成非常大的影響。評估條件分為定性指標和定量指標兩種，理論上講，定量指標能夠更科學客觀地反映軟件的質量特征，但由于并非所有的質量特征都能用定量指標描述，因此不可避免地要采用一些定性指標。一般在選取評估條件時應該遵循如下的幾條原則包括：典型性、簡明性、完備性和客觀性。

同時還要結合我們的主題：金融開源軟件的成熟度評估，在選取評估條件時候也要著重去考慮金融和開源兩個重要的點。

1.2 軟件質量評估標準

結合國家軟件質量評估標準分析開源軟件與傳統軟件的通用評估標準。該步驟的重點是從各個角度對軟件質量進行評價，例如軟件的功能、效率和穩定性等。

國家軟件質量評估標準中定義的評估條件涵蓋一般軟件質量的各個方面，并且具有較強的權威性，如表1所示。

其次，歸納和整理符合開源軟件特性的評估條件。開源軟件從開發、運營的管理到后續服務支持等都有其獨特性，除了軟件自身的，這些開源特性也是軟件選型時的考察重點。經過從五種國際流行的開源軟件評估模型(OSMM Capgemini，OSMM Navica、QSOS、OpenBRR、OMM)的考察，從中選取了較為成熟的三種模型QSOS、OpenBRR和OMM作為參考依據，從而保證整體模型的評估條件有充分的理論支撐。

然后，圍繞金融行業解決方案的特點進一步調整和補充現有評估條件。該步驟根據金融行業解決方案的特點分析各評估條件的重要性，按照評估條件的選取原則和標準對上述過程中得到的評估條件進行補充和整合。

按照以上的標準進行整體模型評估條件的選擇，確定金融開源軟件的成熟度評估標準，并在這個基礎上確定每一條大的標準的子屬性。

1.3 基于開源和金融方向的評估條件補充

1.3.1 基于開源方向的評估標準

開源軟件從開發、運營的管理到后續服務支持等都有其獨特性，在選取開源軟件成熟度整體模型的評估條件時需要充分考慮這些特性。基于此，我們在現有的評估模型中加入了如下的幾條具體一級的屬性，二級要素的選取在這里不展開講述。最后選取的評估條件見表2。

表2 符合開源軟件特性的評估條件

1.3.2 基于金融行業的評估標準

金融行業的組織體系和業務性質都有其自身的特點。在構建金融行業開源軟件成熟度模型時，除了考慮開源軟件與傳統軟件的通用評估項和開源軟件的特性評估項，針對金融行業解決方案的自身特點調整和補充現有評估條件也是十分必要的。對此，我們在整體模型中加入了安全性、服務支持、可靠性等3個具體的評測條目，同樣，這里也不展開二級要素。

1.4 評估條件整合

基于以上的工作，我們可以建立具體的金融開源軟件成熟度評估體系的一級條目，在前期的工作中也確定了每一項一級要素下面的二級條目，從而得到了開源軟件整體模型的評估條件和子屬性，見表3。

續表3

2 評估條件的權重和數學建模

為了具體地去測評某一款開源軟件的各項屬性，量化評價。首先我們需要設計各個子屬性的權重，對于11個一級要素和相對應的二級要素，量化相對應的表現，并根據重要性程度進行權重的建立。

2.1 權重和評分的設計標準

在有評分的項目評估規范中，我們需要為屬性定義他們的權重標準。也就是說每一個屬性類都有他們的權重，權重的參照標準是屬性類一級的權重定義標準；屬性類中的每一個屬性也都有自己的權重，它們權重的參照標準是這一類的參照標準，即一個屬性的權重大小是相對于其同類屬性而言的。

為什么在評估過程中需要使用這種分級加權的評估模型呢？舉例來說，從整體系統來看，就“安全性”屬性類中的“最近6個月修復bug的數量”屬性和“可靠性”屬性類中的“平均失效間隔時間”屬性，很難得出哪個屬性更重要或量化地來看重要多少。

在同一屬性類中不同子屬性間的重要程度就比較好衡量，如，一般情況下“二次開發”屬性類中的“是否提供可供開發的API接口”這一屬性比同類中“是否支持第三方插件”這一屬性對軟件成熟度更為重要一些。

通過對各個屬性類再賦予相應的權重又能比較準確地確定某一類屬性整體上在體系中的重要程度。在類權重和屬性權重的共同作用下，屬性評分經過一定數學模式的計算將獲得較為符合實際情況的軟件成熟度量值。從而提高了評估結果的準確性、實用性。

在這里的評分設計中，我們給每一項具體的二級評測條目按照得到的具體的測試結果給出該軟件在這一項條目中的成熟度評分，在設計時，我們簡單地將軟件的成熟度按照好壞給出了3個具體的檔次，并分別給出了具體的評判標準和得分。值得注意的是，這里我們選取的是一部分簡單的評估條件和測試樣例。在實際的工作中往往需要更加多樣性的條目和更多的檔次來區分軟件的成熟度。

2.2 評估條件和權重設計

在設計屬性類權重和屬性類中各個屬性權重時，我們針對金融云的特殊環境，參考了OpenBRR、OMM、QSOS等現有標準，制定了最終權重標準。

參考表3中的11條具體的一級條目，限于篇幅的原因，這里將挑選其中比較有代表性的5個進行說明，可以用來展現評測模型在權重設計的部分的具體展開方式。將挑選開源許可證、安全性、功能性、效率性和可移植性5個方面來說明具體權重模型的建立和評分方法。

2.2.1 開源許可證

開源軟件許可證相當于“使用合同”，對于這一個極為特殊的屬性，我們將它的權重設置得比較高(20%)。對于金融云平臺開發而言，一般情況下不愿意公開源代碼，而如果使用了GPL許可的開源軟件則會需要公開所有源代碼及所做的修改。因此對于每種參與測評的開源軟件，我們都應該在測評報告中指明其開源許可證。如果許可證不符合要求，那再優秀的其他屬性都大打折扣。

對于開源許可證中的兩個子屬性“開源許可證類別”和“開源許可證沖突檢測”來說，我們認為許可證類別比較重要，而存在的許可證沖突亦不可忽視。因此，我們將許可證類別設置為60%的權重，開源許可證沖突檢測設置為40%的權重。

具體的評分策略見表4，開源許可證類別不明的記為1分，使用GPL、LGPL、OSI許可證的記3分，使用限制較低的符合用戶需求的許可證記為0分。開源許可證沖突檢測的評分按照是否存在軟件公開性與商業保密性的沖突、專利許可授權的沖突、免費使用和盈利的沖突三方面著手。

表4 開源許可證屬性類評分細則

2.2.2 安全性

考慮到金融云的實際環境，我們給安全性設置了比較高的權值(20%)。相較于openBRR和OMM模型，安全性的權值提高了很多。在安全性定義的7項子屬性中，每項屬性的重要性都差不多，因此子屬性權值都設置在14%左右。

具體的評分標準見表5。其中有沒有致力于安全性的信息按照有關安全性的文檔數量打分，相關文檔數量大于15記5分，大于5記3分，其他記1分。

表5 安全性屬性類評分細則

2.2.3 功能性

功能性亦是對金融云十分重要的屬性，我們給予它總分10%的權重占比。在功能性中我們定義了4項目子屬性，分別占比30%、20%、20%和30%。具體如表6所示。

表6 功能性屬性類評分細則

其中，需求功能完成程度，占功能性權重為30%，按照需求的完成程度打分。軟件容錯性，權重為20%，按照處理錯誤的能力記5分或1分。功能準確性，權重為20%，按照功能項目完成的準確程度打分。功能穩定性，按照功能項的穩定程度打分。

2.2.4 效率性

傳統軟件質量指標中，效率性占很大的權重，在金融云的標準中，效率性權重削弱。我們認為效率性和二次開發、可移植性、易用性等屬性應處于同等地位，而低于安全性和功能性等屬性。

對效率性的測評可以定量地轉化成對時間特征和資源特征的測評。在設計測評指標時參考了傳統軟件測試的相關標準。對于輸出結果更新周期，我們每次輸出更新的間隔衡量，以毫秒為單位。處理時間以完成每次任務所需時間衡量，同樣以毫秒為單位。吞吐率則使用每分鐘處理的數據衡量。具體見表7。需要注意的是，對于不同類型的軟件，其測評出的效率性可能差異極大，在具體測評時可以根據需要修正這一屬性的測評值。

表7 效率性評分細則

2.2.5 可移植性

可移植性是傳統軟件質量特性中所考慮的因素，我們賦予它總分10%的權重。可移植性有四項子屬性包括代碼變更率、安裝成功率、功能完整性。評分細則見表8。

表8 可移植性評分細則

其中，代碼變更率是指即軟件為移植而修改的代碼數所占的比率，按照不同的百分比予以打分，比率越低得分越高。安裝成功率即軟件在目標環境下安裝成功的概率，同樣按照概率高低打分，得分與此概率成正比。功能完整性：即軟件在目標環境中維持軟件需求說明中規定功能性的要求，按照全部完成，部分完成和不能完成三級標準打分。

3 開源軟件的整體模型設計

3.1 基于權重的可變多級加權平均模型

有了每一個子屬性的屬性評分的定義，我們就可以將收集到的數據通過一定的規律進行統計和計算得到最后的評分結果。

這里我們提出基于權重的可變多級加權平均模型將收集到的數據通過本模型進行計算可以得最終的評價結果。

對于13個項目一級屬性，首先計算這13項屬性的對應的值，假設每一項屬性有子屬性Pi，其中Pi的權重為Wi，而Pi在該項目上的得分為Si(其中i的取值從1到n，和二級子屬性的具體個數有關)，那么我們可以得到該一級屬性的具體得分為：

(1)

從上一小節中的表格中我們可以看到，每一項一級屬性的最大得分為5分。

接下來要考慮的是，在得到13個具體的一級屬性的得分之后如何去匯總計算。

一個普通的方法是：為所有的一級屬性設置一個權重。

假設有n個一級屬性，每一項一級屬性的得分為Pi，每一項的權重為Wi那么可以得到最后的得分為：

(2)

考慮到不同用戶的需求是不同的，那么不同用戶對不同的一級屬性所給予的關注也是不同的，變化的權重可以照顧到大多數用戶的需求。

3.2 缺少部分數據時按照比例的評測模型

我們在第2節的權重模型中定義了13個大類之下50多個二級條目的評測內容，在理想的情況下可以按照上一小節中的模型來進行具體的成熟度評測工作。但是在測評中我們發現，有些測試數據是比較難以收集的，例如在實際的測評中我們發現，在評測社區活躍度之中的軟件下載數量就比較難去進行界定。另外，在實際的工作中，也比較難去收集到所有的可以評測的條目的具體數據。

這里就需要我們考慮在缺少一部分評測數據條目的情況下如何去進行建模和評測工作。為了保持剩下的數據在評測時的權重比例的特征，這里我們提出一種方法，即在缺少一部分數據條目的情況下將現有的數據條目按照原來的比例去進行評測，按照有具體數據的條目的權重進行權重的重新分配，保證各個屬性項的對比仍然是一致的。

接下來說明如何按照這種方法進行評測工作，我們列舉如下的一個評測場景，見表9。

表9 缺少數據時的Kafka可靠性測試

在如上的測試可靠性的表格之中，該軟件在3個有評測結果的條目中分別得到了8分、7分和9分，但是在其中的可用性一項上面缺少了對應的結果。此時如果按照之前的模型的話，由于缺少其中一項數據就無法給出一個合理的分數。

按照新的比例來評測的話，我們設定3個二級條目的比例為3∶2∶2,得分分別為8、7、9分，在這種情況下重新分配剩余的三項測評條目的權重，可以得到最終的評測結果為：

(8×3+7×2+9×2)/(3+2+2) ≈7.43

使用這一種方法，我們可以在缺少一部分對應的數據的時候仍然可以比較公正地給出該條目的測試結果。

3.3 基于數據規模的可信度參數

在實際的測試過程中，某些條目需要采集具體的數據來判定軟件在這一個方面的成熟性，在測試軟件穩定性的時候就需要運行軟件來觀察軟件在多長的時間之內是可以穩定運行的。而這些數據的采集是具有一定的偶然性的，在多次的測試中也有可能得到偏差比較大的結果。

一個較好的解決方案是對該數據進行重復多次的數據采集，在數據的量足夠大的情況下，該數據的可信程度較高。但是在實際的測試環境中，可能并不一定具有這樣的條件，某些數據的采集可能是開銷比較大的，在這樣的情況下，重復進行多次的數據采集的成本是較高的。

同時，受限于測試環境，某些數據的采集是有一定的局限性的，即無法按照一定的規模來定向收集所有的測試數據。

當測試數據較少的時候，得到的結果和評分是具有一定的偶然性的。這種偶然性是比較難以消除的，但是我們可以在數據量較小的時候，能盡量減小偶然性對我們的測試結果帶來的影響。

為此，我們引入一個可信度參數δ，而δ的最大值為1，在某一項測試數據的數據量較小的時候，δ的數值將相應減小，數據量越大，δ的值就將越大。在數據量達到我們需求的時候，δ的值將被設定為1。

考慮如表10所示的測試場景，我們仍然拿可靠性測試做具體的例子。

表10 加入可信度參數后的Kafka可靠性測試

根據表格中第四欄(數據量)，我們可以給出該測試條目的可置信度。我們可以看到，在測試通過率和穩定性上分別都只有1組的測試數據，因而在這樣的情況下，我們給只有1組測試數據的兩項條目的可置信程度δ=0.5，給有3組數據的條目的可置信制度δ=0.75，而對于有10組測試數據以上的條目的可置信程度δ=1。加入了可置信程度δ之后的加權平均模型，將可以盡量減小因為數據規模較小所帶來的偶然性的影響，在測試中盡量做到客觀而公正的評價。

4 基于模型的對比測試

在整體模型中，我們設計了11個大類的將近40多種不同的權重條目，同時在實際的評測工作中由于測評的展開方式會比較多，整體的測試開展工作是比較復雜的，這里我們會選取其中的若干個大類來進行具體的評測，而不是選取完整的評測條目和結果。

這里我們選取Kafka和RabbitMQ兩款軟件作為我們的測試對象。

考慮到依靠式(1)和式(2)計算權重是簡單的，這里我們主要測試3.2和3.3節中的方法的有效性。

4.1 缺少部分條目的測試結果

Kafka在可靠性方面的得分如表11所示。

表11 無缺少數據時的Kafka可靠性測試

由表11，我們可以根據加權平均模型計算出Kafka在可靠性方面的得分為8.6分。

由表12，由于缺少可用性部分的內容，普通的方式無法計算最終的結果，根據3.2節中的方法可以將剩下的部分按照比例計算得分，由此可以計算出RabbitMQ在可靠性方面的得分為7.42分。可以比較出其中一款軟件在可靠性方面要優于另外一款軟件。在缺少一部分數據的情況下也可以進行計算。

表12 缺少數據時的RabbitMQ可靠性測試

4.2 數據量較小時的測試結果

重新來看上面一個小節中Kafka可靠性的測試結果，但是這次我們加入了可置信度的機制，在這樣的情況下重新計算該款軟件在可靠性上面的得分，如表13所示。得分為8.6分。

表13 Kafka的可靠性測試

加入可置信度機制之后結果如表14所示。

表14 Kafka的可靠性測試(加入可置信度機制之后)

經過重新計算后可以得到得分為8.2分。

可以看到，在加入可信度參數之后，軟件的得分下降了，這是因為數據較小的情況下，可能有一定的偶然性，加入可置信度參數的評價之后可以在一定程度上彌補數據量較小帶來的偶然性。

5 結 語

本文主要考慮了在有較為詳細的金融開源軟件評估體系的條目時。如何去收集數據并且根據一定的權重和建模系統來量化評估金融開源軟件在各個方面的成熟度。

結合具體的實踐例子說明了這樣的權重體系在評價一款軟件的質量時可以起到的作用，同時，使用可以變化權重的多級加權平均模型可以較好地規避數據產生比較大的偏離以及主觀的風險。

這些模型提出了一個比較好的構想，為我們之后進一步金融開源軟件成熟度評估體系提出了新的思路，為接下來的工作給出了一定的鋪墊。