蔡一曉 吳承榮

(復(fù)旦大學(xué)計算機科學(xué)技術(shù)學(xué)院 上海 200433)

0 引 言

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

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

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

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

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

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

1.1 整體模型的流程和方法

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

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

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

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

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

1.2 軟件質(zhì)量評估標準

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

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

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

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

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

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

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

開源軟件從開發(fā)、運營的管理到后續(xù)服務(wù)支持等都有其獨特性，在選取開源軟件成熟度整體模型的評估條件時需要充分考慮這些特性?；诖耍覀冊诂F(xiàn)有的評估模型中加入了如下的幾條具體一級的屬性，二級要素的選取在這里不展開講述。最后選取的評估條件見表2。

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

1.3.2 基于金融行業(yè)的評估標準

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

1.4 評估條件整合

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

續(xù)表3

2 評估條件的權(quán)重和數(shù)學(xué)建模

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

2.1 權(quán)重和評分的設(shè)計標準

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

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

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

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

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

2.2 評估條件和權(quán)重設(shè)計

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

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

2.2.1 開源許可證

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

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

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

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

2.2.2 安全性

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

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

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

2.2.3 功能性

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

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

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

2.2.4 效率性

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

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

表7 效率性評分細則

2.2.5 可移植性

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

表8 可移植性評分細則

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

3 開源軟件的整體模型設(shè)計

3.1 基于權(quán)重的可變多級加權(quán)平均模型

有了每一個子屬性的屬性評分的定義，我們就可以將收集到的數(shù)據(jù)通過一定的規(guī)律進行統(tǒng)計和計算得到最后的評分結(jié)果。

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

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

(1)

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

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

一個普通的方法是：為所有的一級屬性設(shè)置一個權(quán)重。

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

(2)

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

3.2 缺少部分數(shù)據(jù)時按照比例的評測模型

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

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

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

表9 缺少數(shù)據(jù)時的Kafka可靠性測試

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

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

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

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

3.3 基于數(shù)據(jù)規(guī)模的可信度參數(shù)

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

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

同時，受限于測試環(huán)境，某些數(shù)據(jù)的采集是有一定的局限性的，即無法按照一定的規(guī)模來定向收集所有的測試數(shù)據(jù)。

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

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

考慮如表10所示的測試場景，我們?nèi)匀荒每煽啃詼y試做具體的例子。

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

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

4 基于模型的對比測試

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

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

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

4.1 缺少部分條目的測試結(jié)果

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

表11 無缺少數(shù)據(jù)時的Kafka可靠性測試

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

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

表12 缺少數(shù)據(jù)時的RabbitMQ可靠性測試

4.2 數(shù)據(jù)量較小時的測試結(jié)果

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

表13 Kafka的可靠性測試

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

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

經(jīng)過重新計算后可以得到得分為8.2分。

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

5 結(jié) 語

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

結(jié)合具體的實踐例子說明了這樣的權(quán)重體系在評價一款軟件的質(zhì)量時可以起到的作用，同時，使用可以變化權(quán)重的多級加權(quán)平均模型可以較好地規(guī)避數(shù)據(jù)產(chǎn)生比較大的偏離以及主觀的風(fēng)險。

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