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

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

0 引言

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

1 軟件生命周期概述

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

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

2 軟件生命周期質(zhì)量評價(jià)模型

2.1 軟件生命周期質(zhì)量評價(jià)流程

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

bug引入階段指的是在整個軟件生命周期中，哪個階段產(chǎn)生的bug。而在該模型中，bug引入階段包括軟件需求分析階段、軟件設(shè)計(jì)階段、軟件編碼階段和軟件測試階段。需求階段可能因?yàn)樾枨竺枋霾灰桌斫?，有歧義、錯誤等；設(shè)計(jì)階段可能因?yàn)樵O(shè)計(jì)文檔存在錯誤或者缺陷等；編碼階段可能開發(fā)人員代碼出現(xiàn)錯誤等；測試階段可能測試人員操作錯誤等引入了bug，也就是說軟件生命周期任何階段都可能引入bug。

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1 軟件生命周期質(zhì)量評價(jià)流程

2.2 提取度量元

軟件生命周期質(zhì)量評價(jià)方法中，以bug引入階段、bug發(fā)現(xiàn)階段、bug缺陷等級、bug數(shù)量、生命周期不同階段bug產(chǎn)生原因、bug修正系數(shù)6個方面作為度量元，并建立需求階段bug產(chǎn)生原因度量元集合R= {e1,e2,...，ei}，設(shè)計(jì)階段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)生原因度量元權(quán)重系數(shù)計(jì)算

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

直覺模糊集的一些基本概念：設(shè)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成立。進(jìn)一步，稱πA(χi)=1-μA(xi)-νA(χi)為模糊集A中元素χi的猶豫度，a=(μa，νa)是直覺模糊數(shù)，且滿足0≤μa≤1，0≤νa≤1[9-10]；專家分別對不同階段bug產(chǎn)生原因度量元進(jìn)行評價(jià)，采集到需求階段bug產(chǎn)生原因度量元直覺模糊數(shù)，設(shè)計(jì)階段bug產(chǎn)生原因度量元模糊數(shù)，編碼階段bug產(chǎn)生原因度量元模糊數(shù)，測試階段bug產(chǎn)生原因度量元模糊數(shù)，然后采用加權(quán)模糊數(shù)熵權(quán)法確定不同階段bug產(chǎn)生原因度量元的權(quán)重，加權(quán)模糊熵權(quán)法計(jì)算公式為：

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

(1)

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

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

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

(3)

2.4 需求階段質(zhì)量評價(jià)

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

該模型中，從兩個維度對需求階段質(zhì)量減分評價(jià)

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

(4)

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

(5)

式中，RSk為需求階段bug產(chǎn)生原因權(quán)重系數(shù)；rn為需求階段bug產(chǎn)生原因總分類數(shù)；RMk為需求階段bug產(chǎn)生原因?qū)?yīng)的bug缺陷數(shù)量。

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

2.5 設(shè)計(jì)階段質(zhì)量評價(jià)

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

該模型中，從兩個維度對設(shè)計(jì)階段質(zhì)量進(jìn)行減分評價(jià)

維度1：bug引入階段+bug等級+bug數(shù)量，bug引入階段是設(shè)計(jì)階段時(shí)，設(shè)計(jì)階段質(zhì)量評價(jià)第一個減分項(xiàng):

(6)

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

式中，DSk為設(shè)計(jì)階段bug產(chǎn)生原因權(quán)重系數(shù)；dn為設(shè)計(jì)階段bug產(chǎn)生原因總分類數(shù)；DMk為設(shè)計(jì)階段bug產(chǎn)生原因?qū)?yīng)的bug缺陷數(shù)量。

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

2.6 編碼階段質(zhì)量評價(jià)

編碼階段：即軟件編碼，是將設(shè)計(jì)階段得到詳細(xì)設(shè)計(jì)轉(zhuǎn)換為基于某種計(jì)算機(jī)語言的程序，即源程序代碼。

該模型中，從兩個維度對編碼階段質(zhì)量進(jìn)行減分評價(jià)

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

(8)

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

(9)

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

2.7 測試階段質(zhì)量評價(jià)

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

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

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

該模型中，從3個維度進(jìn)行測試階段質(zhì)量減分評價(jià)。

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

(10)

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

(11)

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

(12)

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

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

2.8 總體質(zhì)量評價(jià)

總體質(zhì)量減分評價(jià)公式

S=R+D+C+T

(13)

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

3 測試結(jié)果與分析

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

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

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

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

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

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

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

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

表6 軟件不同階段質(zhì)量評價(jià)結(jié)果

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

S= 2.43+3.57+11.72+6.658=24.378

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

4 結(jié)束語

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