軟件生命周期質量評價方法研究

李海霞，王 磊， 李 智，王月波

(西南電子技術研究所 天奧軟件測評中心，成都 610036)

0 引言

隨著人們對以軟件為核心的載體依賴越來越大，軟件產(chǎn)品質量也成為國際社會密切關注的問題，軟件質量水平很大程度上決定著軟件的市場推廣程度及市場地位[1]。但目前軟件漏洞眾多等問題頻頻出現(xiàn)，軟件質量理所當然地成為了大家關注的焦點，怎么確保被測軟件的質量，并進行提高，從而使用戶更加滿意，已然成為各個國家需要重點解決的熱點和難點問題。大部分企業(yè)均是依據(jù)現(xiàn)有的軟件質量相關標準進行質量評估，但是現(xiàn)有的標準并未對軟件生命周期某個特定的階段進行質量評估，只是從概念上非?；\統(tǒng)的抽象出通用模型[2-5]，特定階段軟件質量評估和實施在我國尚未成熟，并且評估技術大多來自國外軟件質量相關標準，幾乎沒有自主產(chǎn)權的有特色的評估體系[6-9]。另外，對于軟件生命周期中和軟件的質量問題最為密切相關的幾個階段，包括需求分析、軟件設計、軟件編碼和軟件測試，一方面缺乏對定性和定量指標的提取，另一方面，也未形成科學嚴謹?shù)碾A段質量評價模型。因此迫切需要制定一套專門針對軟件生命周期中需求分析、軟件設計、軟件編碼和軟件測試的質量評價方法，該評價方法具有非常重大的現(xiàn)實意義。

1 軟件生命周期概述

和世界萬物類似，一個成熟的軟件需要經(jīng)歷孕育、誕生、成長、成熟、衰亡等階段，一般我們稱之為軟件生存周期(又叫軟件生命周期)[10]。一般情況下，軟件生命周期主要包括軟件需求分析、軟件設計、軟件編碼、軟件測試和軟件維護等階段，軟件測試[11]是一個系列過程，包括軟件測試需求分析、軟件測試計劃設計、軟件測試用例設計、軟件測試執(zhí)行等等，軟件生命周期各個階段均進行不同目的和內(nèi)容的測試活動，因此，軟件項目整個生命周期中均存在軟件測試，從而確保軟件生命周期各個階段均正常使用。此外，軟件生命周期各個過程均可能存在錯誤，軟件測試只能確認軟件存在的錯誤，并不能避免軟件新錯誤的出現(xiàn)。

在整個軟件生命周期中，其中軟件需求分析、軟件設計、軟件編碼和軟件測試等4個階段和軟件質量息息相關。軟件需求分析是對產(chǎn)品進行定義，軟件設計是進行產(chǎn)品設計，軟件編碼是實現(xiàn)軟件，軟件測試則是驗證軟件是否滿足需求。軟件的質量控制有個很明顯的特點，那就是發(fā)現(xiàn)軟件問題越早，解決該軟件問題的成本就會越低，反之則越高，這是因為軟件問題可能出現(xiàn)在軟件需求分析、軟件設計和軟件編碼、軟件測試這幾個階段的任意階段，而在實際軟件生命周期中，軟件問題很多是等到了后面階段才被發(fā)現(xiàn)，但此時很多工作已經(jīng)基于這個錯誤的前提下進行了開展，而且引入問題的階段越是靠前，其影響范圍也就會越廣，而且解決軟件質量問題的成本是和開發(fā)階段呈指數(shù)級別增長的，所以越是到后面，需要投入的人力成本和時間等成本也就會越多。因此，對軟件生命周期每個階段分別進行評價，建立合適的軟件生命周期質量評價方法就尤其重要。

2 軟件生命周期質量評價模型

2.1 軟件生命周期質量評價流程

軟件缺陷(bug)：軟件在使用過程中存在的任何問題都稱為軟件的缺陷，簡稱bug。

bug引入階段指的是在整個軟件生命周期中，哪個階段產(chǎn)生的bug。而在該模型中，bug引入階段包括軟件需求分析階段、軟件設計階段、軟件編碼階段和軟件測試階段。需求階段可能因為需求描述不易理解，有歧義、錯誤等；設計階段可能因為設計文檔存在錯誤或者缺陷等；編碼階段可能開發(fā)人員代碼出現(xiàn)錯誤等；測試階段可能測試人員操作錯誤等引入了bug，也就是說軟件生命周期任何階段都可能引入bug。

bug發(fā)現(xiàn)階段指的是在整個軟件生命周期中，哪個階段發(fā)現(xiàn)的bug。而在該模型中，bug發(fā)現(xiàn)階段包括軟件需求分析階段、軟件設計階段、軟件編碼階段和軟件測試階段。bug發(fā)現(xiàn)階段一般晚于bug引入階段，一般來說，bug發(fā)現(xiàn)的越早，修復的成本越低，反之，bug發(fā)現(xiàn)的越晚，修正該bug所付出的代價就越高，而且修復代價呈指數(shù)級增長。

bug缺陷等級：按照bug對被測系統(tǒng)的影響程度，可分為關鍵缺陷、嚴重缺陷、一般缺陷、建議改進。

關鍵缺陷：非常嚴重的缺陷，比如軟件或系統(tǒng)癱瘓、異常退出、頻繁的死機，軟件或系統(tǒng)重要部件無法正常運行，從而嚴重影響軟件或系統(tǒng)功能的正常運行，均定義為關鍵缺陷。

嚴重缺陷：嚴重地影響軟件或系統(tǒng)要求，或未實現(xiàn)基本功能，主要功能無法執(zhí)行、或數(shù)據(jù)被破壞、或產(chǎn)生錯誤結果，而且是在用戶常規(guī)操作中頻繁出現(xiàn)，或者非常規(guī)操作中無法避免的主要問題，軟件或系統(tǒng)無法滿足重要的業(yè)務需求，或錯誤設計配置項或配置項后測試中發(fā)現(xiàn)配置有關的問題等。

一般缺陷：軟件或系統(tǒng)基本滿足用戶業(yè)務要求，但次要功能喪失，或通過變通手段可以解決，或安裝手冊或部署文檔錯誤而導致安裝部署軟件失敗，或對應的業(yè)務流程功能未實現(xiàn)，但有替代方法來解決，或系統(tǒng)響應時間變慢、產(chǎn)生錯誤的中間結果但不影響實際使用等影響有限的問題。包括性能問題、安全問題、校驗問題、亂碼等。

建議改進：使操作者不方便或操作麻煩，但不影響執(zhí)行工作功能或重要功能。包括界面問題、提示信息、易用性、統(tǒng)一性等，希望提出的建議但不強制進行的修改。

bug數(shù)量：該評價模型中，指的是確認修改的bug數(shù)量，撤回的bug數(shù)量不計入該模型。

bug產(chǎn)生原因：通過查閱某測評中心近5年的測試報告記錄，提煉總結出常見的缺陷產(chǎn)生原因，并根據(jù)軟件生命周期不同階段分別劃分，具體bug產(chǎn)生原因詳見表1所示。

表1 軟件生命周期不同階段bug產(chǎn)生原因度量元

度量元：通常用來對軟件或系統(tǒng)進行量化管理時，需要重點關注信息對象的基本屬性的描述。依據(jù)度量數(shù)據(jù)獲取方式，可以把度量元劃分為基本度量元(又稱為直接度量元)和派生度量元(又稱為間接度量元)兩種?；径攘吭?，顧名思義，其數(shù)據(jù)來源可直接度量獲得，派生度量元，其數(shù)據(jù)來源于其他的數(shù)據(jù)，一般由兩個或多個基本度量元組合獲得。在該評價模型中，為了量化軟件生命周期不同階段質量，采取基本度量元方式，以下簡稱度量元。

熵權法：是統(tǒng)計學領域一種客觀賦權方法，在統(tǒng)計學領域中，但數(shù)據(jù)越分散，熵值越小，可以認為該數(shù)據(jù)包含信息越多，因此權重越大。在具體使用過程中，根據(jù)各指標的數(shù)據(jù)的分散程度，利用信息熵計算出各指標的熵權，再根據(jù)各指標對熵權進行一定的修正，從而得到較為客觀的指標權重。

為了能夠客觀地評價軟件生命周期不同階段質量，針對需求分析、軟件設計、軟件編碼和軟件測試這4個階段，分別從bug引入階段、bug發(fā)現(xiàn)階段、bug缺陷等級[12]、bug數(shù)量、bug產(chǎn)生原因、bug修正代價6個方面，篩選體現(xiàn)每個階段質量的度量元，對每個度量元進行定義，并采用改進的加權模糊熵權法[13- 17]確定每個度量元的權重系數(shù)，減少主觀因素干擾，提高度量元權重系數(shù)客觀性，從而建立起一套行之有效的計算方法和評價機制。

該評價模型主要分以下幾步。第1步：提取度量元，以bug引入階段、bug發(fā)現(xiàn)階段、bug缺陷等級、bug數(shù)量、生命周期不同階段bug產(chǎn)生原因、bug修正系數(shù)6個方面作為度量元；第2步：bug產(chǎn)生原因度量元權重系數(shù)計算，為減少主觀因素干擾，采用改進的加權模糊熵權法確定權重系數(shù)；第3步：需求階段質量評價；第4步，設計階段質量評價；第5步：編碼階段質量評價；第6步：測試階段質量評價；第7步，總體質量評價。整個評價流程如圖1所示。

圖1 軟件生命周期質量評價流程

2.2 提取度量元

軟件生命周期質量評價方法中，以bug引入階段、bug發(fā)現(xiàn)階段、bug缺陷等級、bug數(shù)量、生命周期不同階段bug產(chǎn)生原因、bug修正系數(shù)6個方面作為度量元，并建立需求階段bug產(chǎn)生原因度量元集合R= {e1,e2,...，ei}，設計階段bug產(chǎn)生原因度量元集合D={d1,d2，...，dj}，編碼階段bug產(chǎn)生原因度量元集合C={c1,c2，...，cj}，測試階段bug產(chǎn)生原因度量元集合T={t1,t2，...，tj}。

2.3 Bug產(chǎn)生原因度量元權重系數(shù)計算

為了減少主觀因素干擾，提高度量元權重系數(shù)客觀性，采用改進的加權模糊數(shù)熵權法，首先應用模糊數(shù)來表示多名專家對bug產(chǎn)生原因度量元做出的評價結果，建立直覺模糊集合。

直覺模糊集的一些基本概念：設X為一給定的論域，則稱A={<χi,μA(xi),νA(χi)>|χi∈X}為X上的一個直覺模糊集。其中μA：X→[0,1]和νA：X→[0,1]分別為A的隸屬度和非隸屬度函數(shù)，且對于任意的χi∈X，有0≤μA(χi)+νA(χi)≤1成立。進一步，稱πA(χi)=1-μA(xi)-νA(χi)為模糊集A中元素χi的猶豫度，a=(μa，νa)是直覺模糊數(shù)，且滿足0≤μa≤1，0≤νa≤1[9-10]；專家分別對不同階段bug產(chǎn)生原因度量元進行評價，采集到需求階段bug產(chǎn)生原因度量元直覺模糊數(shù)，設計階段bug產(chǎn)生原因度量元模糊數(shù)，編碼階段bug產(chǎn)生原因度量元模糊數(shù)，測試階段bug產(chǎn)生原因度量元模糊數(shù)，然后采用加權模糊數(shù)熵權法確定不同階段bug產(chǎn)生原因度量元的權重，加權模糊熵權法計算公式為：

假設X={x1，x2，xi，xn}，A={<χi,μA(xi),νA(χi)>|χi∈X}為專家給出的模糊集，則模糊集的熵計算公式為：

(1)

考慮到bug產(chǎn)生原因權重信息的客觀性，減少專家判斷的主觀性，以bug產(chǎn)生原因問題個數(shù)占比作為加權系數(shù)，提出bug產(chǎn)生原因度量元權重公式為：

式中，nm為軟件生命周期不同bug產(chǎn)生原因度量元對應的問題數(shù)；Nm為軟件生命周期不同bug產(chǎn)生原因度量元對應的問題總數(shù)。

進行歸一化處理，最終bug產(chǎn)生原因度量元權重計算公式為：

(3)

2.4 需求階段質量評價

需求階段：即軟件需求分析階段，是開發(fā)人員經(jīng)過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求轉述為完整的需求定義，從而確定系統(tǒng)必須做什么的過程。

該模型中，從兩個維度對需求階段質量減分評價

維度1：bug引入階段+bug等級+bug數(shù)量，在bug引入階段是需求階段時，提出需求階段質量評價第一個減分項公式

(4)

維度2：bug引入階段+bug數(shù)量+bug產(chǎn)生原因，在bug引入階段是需求階段時，提出需求階段質量評價第二個減分項

(5)

式中，RSk為需求階段bug產(chǎn)生原因權重系數(shù)；rn為需求階段bug產(chǎn)生原因總分類數(shù)；RMk為需求階段bug產(chǎn)生原因對應的bug缺陷數(shù)量。

從而定義需求階段質量評價減分項R=R1+R2，R越大，表明需求階段質量越不好，在后續(xù)項目中越需要加強需求人員的能力。

2.5 設計階段質量評價

設計階段：即軟件設計，是從軟件需求規(guī)格說明書出發(fā)，根據(jù)需求分析階段確定的功能設計軟件系統(tǒng)的整體結構、劃分功能模塊、確定每個模塊的實現(xiàn)算法以及編寫具體的代碼，形成軟件的具體設計方案。

該模型中，從兩個維度對設計階段質量進行減分評價

維度1：bug引入階段+bug等級+bug數(shù)量，bug引入階段是設計階段時，設計階段質量評價第一個減分項:

(6)

維度2：bug引入階段+bug數(shù)量+bug產(chǎn)生原因，設計階段質量評價第二個減分項:

式中，DSk為設計階段bug產(chǎn)生原因權重系數(shù)；dn為設計階段bug產(chǎn)生原因總分類數(shù)；DMk為設計階段bug產(chǎn)生原因對應的bug缺陷數(shù)量。

從而定義階段質量評價減分項D=D1+D2，D越大，表明設計階段質量越不好，在后續(xù)項目中越需要加強設計人員的能力；

2.6 編碼階段質量評價

編碼階段：即軟件編碼，是將設計階段得到詳細設計轉換為基于某種計算機語言的程序，即源程序代碼。

該模型中，從兩個維度對編碼階段質量進行減分評價

維度1：bug引入階段+bug等級+bug數(shù)量，bug引入階段是編碼階段時，編碼階段質量評價第一個減分項公式:

(8)

維度2：bug引入階段+bug數(shù)量+bug產(chǎn)生原因，bug引入階段是設計階段時，編碼階段質量評價第二個減分項公式:

(9)

從而定義編碼階段質量評價減分項C=C1+C2，C越大，表明編碼階段質量越不好，在后續(xù)項目中越需要加強編碼人員的能力；

2.7 測試階段質量評價

測試階段：即軟件測試，描述一種用來促進鑒定軟件的正確性、完整性、安全性和質量的過程。換句話說，軟件測試是一種實際輸出與預期輸出之間的審核或者比較過程。軟件測試的經(jīng)典定義是：在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質量，并對其是否滿足設計要求進行評估的過程。

測試階段質量評價不同于其他階段，本發(fā)明中，對于bug發(fā)現(xiàn)階段晚于bug引入階段的情況，測試階段質量評價中也需要扣分。統(tǒng)計資料顯示在需求階段修正一個錯誤的代價假如是1，則在設計階段就是它的2～3倍，在編碼階段就是它的5～8倍，在測試階段就是它的20～30倍[18-19]，修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數(shù)增長的，軟件的質量問題越到后面解決成本越高。根據(jù)修正錯誤的代價大小，確定需求階段錯誤修正代價系數(shù)是1，設計階段錯誤修正代價系數(shù)是e，編碼階段錯誤修正代價系數(shù)是e2，測試階段錯誤修正系數(shù)是e3，歸一化處理后各個階段bug修正代價權重系數(shù)如表2所示。

表2 軟件生命周期不同階段bug修正代價系數(shù)

該模型中，從3個維度進行測試階段質量減分評價。

維度1：bug引入階段+bug等級+bug數(shù)量，bug引入階段是測試階段時，測試階段質量評價第一個減分項公式:

(10)

維度2：bug引入階段+bug數(shù)量+bug產(chǎn)生原因，bug引入階段是測試階段時，測試階段質量評價第二個減分項公式:

(11)

維度3：bug引入階段+bug發(fā)現(xiàn)階段+bug修正系數(shù)，bug引入階段是測試階段時，測試階段質量評價第三個減分項:

(12)

式中，Yk為bug引入階段，本發(fā)明中把需求階段定義為1，設計階段定義為2，編碼階段定義為3，測試階段定義為4；Fk為bug發(fā)現(xiàn)階段，本發(fā)明中均定為測試階段，n=4；P為bug引入階段對應的修正系數(shù)，參見表2。

從而定義測試階段質量評價減分項T=T1+T2+T3，T越大，表明測試階段質量評價越不好，在后續(xù)項目中越需要加強測試人員的能力。

2.8 總體質量評價

總體質量減分評價公式

S=R+D+C+T

(13)

式中，R為需求階段質量減分評價；D為設計階段質量減分評價；C為編碼階段質量減分評價；T為測試階段質量減分評價。S越大，表明該軟件總體質量越差。

3 測試結果與分析

從某具有豐富經(jīng)驗的XX測評中心機構中，查找近5年測試報告記錄，從中篩選中各個階段bug產(chǎn)生原因，定義軟件生命周期不同階段度量元詳見表2。

首先邀請5位具有專業(yè)知識的軟件測評專家，分別對需求分析、設計、編碼和測試階段bug產(chǎn)生原因進行評價，為了對不同階段bug產(chǎn)生原因之間的重要程度進行定量的描述，定義如表3所示的標度[20]，括號3個數(shù)字代表(μij,νij,πij)。

表3 bug產(chǎn)生原因重要程度定義的標度表

根據(jù)表3，各位專家兩兩比較軟件生命周期不同階段bug產(chǎn)生原因重要程度，并以某XX軍用模擬訓練系統(tǒng)中系統(tǒng)數(shù)據(jù)管理軟件為例，其不同階段對應問題數(shù)如表4所示。

表4 軟件不同階段對應問題數(shù)

以專家給出的直覺模糊數(shù)為基礎，利用公式(1)～(3)計算軟件不同階段bug產(chǎn)生原因權重系數(shù)，如表5所示。

表5 軟件不同階段bug產(chǎn)生原因權重系數(shù)

利用公式(4)～(13)，分別計算軟件生命周期不同階段質量減分評價，如表6所示。

表6 軟件不同階段質量評價結果

根據(jù)公式(14)，計算該軟件總體質量評價

S= 2.43+3.57+11.72+6.658=24.378

從表6中可以看出，被評軟件中需求分析階段評分結果為2.43，設計階段評分結果為3.57，編碼階段評分結果為11.72，測試階段評分結果為6.658，軟件總體質量評分結果是24.378。該軟件生命周期不同階段質量優(yōu)劣順序為需求分析階段>設計階段>測試階段>編碼階段，故對于項目組管理人員來說，需要重點關注編碼階段質量，提高編碼人員能力。經(jīng)對數(shù)據(jù)做人工分析，可以看出評價的結果和新設計的計算準則是基本吻合。

4 結束語

目前的軟件質量評估標準一方面只是從概念上定義了一個籠統(tǒng)抽象的通用模型來評估整個軟件的質量，另外一方面缺乏針對軟件生命周期不同階段質量評估模型。針對這些問題，對軟件生命周期中和軟件質量問題最為密切相關的幾個階段，包括需求分析、軟件設計、軟件編碼和軟件測試，制定了新的軟件生命周期質量評價方法，分析度量元，并提出改進的加權模糊熵權法確定加權系數(shù)，給出評價方法和評價流程，最后通過實例對方法進行了有效驗證，為軟件生命周期不同階段質量建立了一套有效的評價標準。當然，評價標準需要經(jīng)過實踐不斷驗證和不斷的改良，評價度量元和加權系數(shù)也是需要在實踐中不斷的驗證而修改和補充。