軟件度量

早在1958年，Rubey和Hurtwick就提出了軟件度量。軟件度量學基礎性工作的建立始於20世紀60年代末，主要展開於70年代，而進一步的開展主要在80-90年代。國外採用度量來衡量軟件質量在70年代末已經出現，並在90年代獲得了空前的發展，成為軟件工程研究中的熱點方向之一。自20世紀70年代中期以來，美國建立了各種各樣的軟件度量組織，開展了相關活動，並且得到美國卡耐基梅隆大學軟件工程研究所（SEI）的大力支持。 ^[1] 

1986年英國啓動了“基於結構的軟件度量”的研究項目，目的是在現有研究基礎上，建立標準模型，分析和度量軟件結構。1989-1992年，歐共體創立了METKIT項目，目的是通過開發面向工程和學術界的教材來喚起相關人員的度量意識和提高軟件度量在歐洲工程界的應用。20世紀90年代末，德國有幾家公司應用軟件度量，如西門子、博世等。 ^[1] 

自20世紀末以來，中國才開始進行軟件度量方面的研究，主要有北京航空航天大學、中國科學院軟件研究所、合肥工業大學、南京航空航天大學、南京大學國家重點實驗室、復旦大學、華東理工大學、北京工業大學、華東理工大學等研究所和大學。從發表的論文看，國內的研究以軟件產品度量研究為主，關注軟件過程方面的研究較少。國內的有關研討會也對軟件度量給予了較大的關注。每年由中國計算機學會軟件工程專業委員會主辦的全國軟件與應用學術會議（NASAC）都有軟件度量方面的論文發表。 ^[1] 

軟件度量過程分為如下四步：第一步，利用度量（metric）將現實世界中的實體屬性映射為數值世界中的數值（或者符號）；第二步，在數值上進行統計分析，得到統計量；第三步，對實驗結果進行解釋；第四步，將所得的解釋和現實世界中的經驗關係進行對照，驗證其正確性。為了得到真正有用的度量，在第一步中定義的度量需滿足表達條件（representationcondition），使得實體在特定屬性上的經驗關係在數值關係中能得到保留。在第二步，需根據度量的刻度類型(scaletype)確定度量值上可進行什麼樣的統計分析。在第三步，需要清楚對分析結果進行什麼樣的解釋是有意義的。在第四步，驗證所提出的度量是否真的量化了所想要量化的實體屬性。 ^[3] 

軟件度量能夠為項目管理者提供有關項目的各種重要信息，其實質是根據一定規則，將數字或符號賦予系統、構件、過程或者質量等實體的特定屬性，即對實體屬性的量化表示，從而能夠清楚地理解該實體。軟件度量貫穿整個軟件開發生命週期，是軟件開發過程中進行理解、預測、評估、控制和改善的重要載體。軟件質量度量建立在度量數學理論基礎之上。軟件度量包括3個維度，即項目度量、產品度量和過程度量。

在軟件開發中，軟件度量的根本目的是為了管理的需要。利用度量來改進軟件過程。人們是無法管理不能度量的事物。在軟件開發的歷史中，我們可以意識到，在60年代末期的大型軟件所面臨的軟件危機反映了軟件開發中管理的重要性。而對於管理層人員來説：沒有對軟件過程的可見度就無法管理；而沒有對見到的事物有適當的度量或適當的準則去判斷、評估和決策，也無法進行優秀的管理。我們説軟件工程的方法論主要在提供可見度方面下工夫。但僅僅是方法論的提高並不能使其成為工程學科。這就需要使用度量。度量是一種可用於決策的可比較的對象。度量已知的事物是為了進行跟蹤和評估。對於未知的事物，度量則用於預測。本專題將討論軟件度量的一些基本問題。但應認識到軟件度量的成果是非常初步的，還需要大量工作才可能真正地做到實用化，但它的實用化成就將對軟件的高質量和高速發展有不可估量的影響。那麼， 一、什麼是度量呢?

度量存在於左右我們生活的很多系統的核心之中。在經濟領域，度量決定着價格和付款的增加；在雷達系統中，度量使我們能透過雲層探測到飛機；在醫療系統中，度量使得能夠診斷某些特殊疾病；在天氣預測系統中，度量是天氣預報的基礎；沒有度量，技術的發展根本無法進行。度量的正式定義是: 度量 是指在現實的世界中，把數字或符號指定給實體的某一屬性， 以便以這種方式來根據已明確的規則來描述它們.

因此，度量關注的是獲取關於實體屬性的信息。一個實體可以是一個實物，如人或房間；或者是一個事件，如旅行；或軟件項目的測試階段。屬性是我們所關注的實體的特徵或特性，如血壓的高度（人）、時間（測試階段）、範圍或顏色（房間）、花銷（旅行） 等。因此，説"度量事物"或"度量屬性"的説法是不完全正確的；應該説"度量事物的屬性"。"度量房間"的説法是模糊的；我們可以説度量它的長度、範圍和温度等。同樣説"度量温度"的説法也是模糊的，應該説：我們度量的是某一特定地理位置和特定情況下的温度。

如在設計電路的時候我們應用歐姆定律。這個定律描述了電路中電阻、電流和電壓三者之間的關係。但是這些理論已超出了一般意義上的科學方法的範疇，在這種範疇裏最基本的東西是度量。度量除了在發展一個理論的過程中起作用外，我們使用度量並應用它們。因此設計一個特定電流和電阻的電路時我們就知道需要多大的電壓。

如果沒有度量，我們很難想象關於電子、機械、及普通工程的定律能得到發展。但事實上在軟件工程的主流裏度量卻被忽略了。

情況是：

■當我們在設計和開發軟件產品的時候，我們並未能制定出度量的目標。例如：我們保證説我們將使用户界面友好、可靠、易於維護；而並未使用度量的術語來詳細説明它們的具體含義。Gilb曾經説過：所謂模糊目標定理，就是沒有明確目標的項目將不能明確地達到它的目標。

■我們未能對構成軟件項目實際費用的各個不同的部分進行有效的度量。譬如：通常我們並不知道，和測試階段相比，設計階段花費時間多大。

■我們並未試圖使我們開發的產品的各種質量合格。因此我們未能使用術語（如：在一段時間裏使用故障的可能性、把產品安裝到新環境中需花費的工作量等）向潛在的用户説明產品的可靠性很高。

■我們總是試圖説服自己使用另一種新的革新的開發技術和方法進行軟件開發

事實上，我們在軟件度量方面做的工作很少很少，而且所作的度量方面的工作也與一般科學意義上的度量相分離。我們經常會看到諸如此類的話："軟件的費用有80%花費在維護上。"或"軟件每一千行程序中平均有55個Bugs。"。但是這些話並沒有告訴我們這樣的結果是怎樣產生的、試驗是怎樣設計、執行的、度量的是那個實體、及錯誤的框架是什麼等等。沒有這些東西，我們就不能在我們自己的環境中客觀地進行反覆度量，重現度量的結果以獲得與工業標準的真實比較。因此，歸因於度量不充分的問題的產生是由於缺乏嚴格的度量方法造成的。

除了傳統的對計算機硬件的性能進行度量外，對算法的複雜性的度量一直是計算機科學的重要組成部分。但是，這種度量方法只適用於小程序，而對大型、複雜的軟件來説它卻無能為力了。這就屬於軟件工程的範疇了。如果我們不承認度量將會一個更重要的作用的話，軟件危機將在隨後的幾年裏依然存在

隨着軟件定量方法（如：軟件度量）的重要性不斷增加，市場上出現了許多度量工具。然而，度量工具還是很混亂。因為沒有統一的度量標準規範，每種工具發明商家都是按照他們自己的軟件度量規範。文獻[44]對度量工具做了好的綜述。Daich等根據分類學把度量工具分成了以下幾種：

● 通用度量工具；

● 小生境度量工具（Niche Metrics Tool）；

● 靜態分析；

●源代碼靜態分析；

● 規模度量

軟件開發正在經受一場危機。費用超支（特別是在維護階段的花費太大）、生產率低下、 以及質量不高等問題正困擾着它。簡言之，軟件開發經常處於失控狀態。軟件之所以失控是因為沒有度量。Tom Demarco曾經説過："沒有度量就不能控制。"這種説法是好的，但不完全。並不能説為了獲得控制必須進行度量。度量活動必須有明確的目標或目的，而正是這決定着我們選擇哪種屬性和實體進行度量。這個目標與軟件開發、使用時所涉及的人的層次有關。

以下主要從管理者和軟件工程師兩種角度來考慮，為了達到各種目標所要進行的度量工作。

1.需要度量軟件開發過程中的不同階段的費用。

例如：度量開發整個軟件系統的費用（包括從需求分析階段到發佈之後的維護階段）。必須清楚這個費用以決定在保證一定的利潤的情況下的價格。

2.為了決定付給不同的開發小組的費用，需要度量不同小組職員的生產率。

3.為了對不同的項目進行比較、對將來的項目進行預測、建立基線以及設定合理的改進目標等，需要度量開發的產品的質量。

4.需要決定項目的度量目標。例如：應達到多大的測試覆蓋率、系統最後的可靠性應有多大等。

5.為了找出是什麼因素影響着費用和生產率，需要反覆測試某一特定過程和資源的屬性。

6.需要度量和估計不同軟件工程方法和工具的效用，以便決定是否有必要把它們引入到公司中。

1.需要制定過程度量以監視不斷演進的系統。這包括設計過程中的改動、在不同的回顧或測試階段發現的錯誤等等。

2.需使用嚴格的度量的術語來指定對軟件質量和性能的要求，以便使這些要求是可測試的。例如：系統必須"可靠"，可用如下的更具體 的文字加以描述："平均錯誤時間必須大於15個CPU時間片。"

3.為了合格需要度量產品和過程的屬性。例如：看一個產品是否合格要看產品的一些可度量的特性如"β測試階段少於20個錯誤。"，"每個模塊的代碼行不超過100行。"，和開發過程的一些屬性如"單元測試必須覆蓋90%以上的用例。"等。

4.需要度量當前已存在的產品和過程的屬性以便預測將來的產品。例如：

（1）.通過度量軟件規格説明書的大小來預測目標? 的大小。

（2）.通過度量設計文檔的結構特性來預測將來維護的"盲點"。

（3）.通過度量測試階段的軟件的可靠性來預測軟件今後操作、運行的可靠性。

研究上面我們列出的度量的目標和活動我們可以發現：軟件度量的目標可大致 概括為兩類。

其一，我們使用度量來進行估計。這使得我們可以同步地跟蹤一個特定的軟件項目 。

其二，我們應用度量來預測項目的一些重要的特性。但是，值得指出的是我們不能 過分誇大這些預測。因為它們並不是完全正確的。軟件度量得到也僅僅是預測而已。有些人甚至認為只要使用合適的模型和工具，所獲得的預測可以精確到只需使用極少的其他度量（甚至根本就不用使用度量）。事實上，這種期望是不現實的。

項目度量是針對軟件開發項目的特定度量，目的在於度量項目規模、項目成本、項目進度、顧客滿意度等，輔助項目管理進行項目控制。

軟件開發項目規模度量（size measurement）是估算軟件項目工作量、編製成本預算、策劃合理項目進度的基礎。規模度量是軟件項目失敗的重要原因之一。一個好的規模度量模型可以解決這一問題。有效的軟件規模度量是成功項目的核心要素：基於有效的軟件規模度量可以策劃合理的項目計劃，合理的項目計劃有助於有效地管理項目。規模度量的要點在於：由開發現場的項目成員進行估算；靈活運用實際開發作業數據；杜絕盲目迎合顧客需求的“交期逆推法”。

軟件規模度量有助於軟件開發團隊準確把握開發時間、費用分佈以及缺陷密度等等。軟件規模的估算方法有很多種，如：功能點分析（FPA：function points analysis）、代碼行（LOC：lines of code）、德爾菲法（Delphi technique）、COCOMO模型、特徵點（feature point）、對象點（object point）、3-D功能點（3-D function points）、Bang度量（DeMarco's bang metric）、模糊邏輯（fuzzy logic）、標準構件法（standard component）等，這些方法不斷細化為更多具體的方法。

軟件開發成本度量主要指軟件開發項目所需的財務性成本的估算。主要方法如下：

類比估算法。類比估算法是通過比較已完成的類似項目系統來估算成本，適合評估一些與歷史項目在應用領域、環境和複雜度方面相似的項目。其約束條件在於必須存在類似的具有可比性的軟件開發系統，估算結果的精確度依賴於歷史項目數據的完整性、準確度以及現行項目與歷史項目的近似程度。

細分估算法。細分估算法是將整個項目系統分解成若干個小系統，逐個估算成本，然後合計起來作為整個項目的估算成本。細分估算法通過逐漸細化的方式對每個小系統進行詳細的估算，可能獲得貼近實際的估算成本。其難點在於，難以把握各小系統整合為大系統的整合成本。

週期估算法。週期估算法是按軟件開發週期進行劃分，估算各個階段的成本，然後進行彙總合計。週期估算法基於軟件工程理論對軟件開發的各個階段進行估算，很適合瀑布型軟件開發方法，但是需要估算者對軟件工程各個階段的作業量和相互間的比例具有相當的瞭解。

顧客滿意是軟件開發項目的主要目的之一，而顧客滿意目標要得以實現，需要建立顧客滿意度度量體系和指標對顧客滿意度進行度量。顧客滿意度指標（CSI：customer satisfaction index）以顧客滿意研究為基礎，對顧客滿意度加以界定和描述。項目顧客滿意度量的要點在於：確定各類信息、數據、資料來源的準確性、客觀性、合理性、有效性，並以此建立產品、服務質量的衡量指標和標準。企業顧客滿意度度量的標準會因為各企業的經營理念、經營戰略、經營重點、價值取向、顧客滿意度調查結果等因素而有所不同。比如：NEC於2002年12月開始實施的CSMP 活動的度量尺度包括共感性、誠實性、革新性、確實性和迅速性，其中，將共感性和誠實性作為CS活動的核心姿態，而將革新性、確實性和迅速性作為提供商品和服務中不可或缺的尺度。每個尺度包括兩個要素，各要素包括兩個項目，共計5大尺度、10個要素和20個項目。例如，共感性這一尺度包括“瞭解顧客的期待”、“從顧客的立場考慮問題”這兩個要素；“瞭解顧客的期待”這一要素又包括“不僅僅能勝任目前的工作還能意識到為顧客提供價值而專心投入”、“對顧客的期望不是囫圇吞棗而是根據顧客的立場和狀況來思考‘顧客到底需要什麼’並加以應對”這兩個項目。

美國專家斯蒂芬（Stephen H.Kan）在《軟件質量工程的度量與模型》（Metrics and Models in Software Quality Engineering）中認為，企業的顧客滿意度要素如表7-1所示：

作為企業的顧客滿意度的基本構成單位，項目的顧客滿意度會受到項目要素的影響，主要包括：開發的軟件產品、開發文檔、項目進度以及交期、技術水平、溝通能力、運用維護等等。具體而言，可以細分為如表7-2所示的度量要素，並根據這些要素進行度量。

顧客滿意度項目 顧客滿意度度量要素

軟件產品 功能性、可靠性、易用性、效率性、可維護性、可移植性

開發文檔 文檔的構成、質量、外觀、圖表以及索引、用語

項目進度以及交期 交期的根據、進度遲延情況下的應對、進展報告

技術水平 項目組的技術水平、項目組的提案能力、項目組的問題解決能力

溝通能力 事件記錄、式樣確認、Q&A

運用維護 支持、問題發生時的應對速度、問題解決能力

軟件產品度量用於對軟件產品進行評價，並在此基礎之上推進產品設計、產品製造和產品服務優化。軟件產品的度量實質上是軟件質量的度量，而軟件的質量度量與其質量的週期密切相關。

軟件產品的度量主要針對作為軟件開發成果的軟件產品的質量而言，獨立於其過程。軟件的質量由一系列質量要素組成，每一個質量要素又由一些衡量標準組成，每個衡量標準又由一些量度標準加以定量刻劃。質量度量貫穿於軟件工程的全過程以及軟件交付之後，在軟件交付之前的度量主要包括程序複雜性、模塊的有效性和總的程序規模，在軟件交付之後的度量則主要包括殘存的缺陷數和系統的可維護性方面。一般情況下，可以將軟件質量特性定義成分層模型。勃姆（Barry W. Boehm）在《軟件風險管理》（Software Risk Management）中第一次提出了軟件質量度量的層次模型。而麥考爾（McCall）等人將軟件質量分解至能夠度量的層次，提出FCM 3層模型（參見表5-13）：軟件質量要素（factor）、衡量標準（criteria）和量度標準（metrics），包括11個標準，分為產品操作（product operation）、產品修正（product revision）和產品轉移（product transition）。ISO 9126將軟件質量總結為6大特性，每個特性包括一系列副特性，其軟件質量模型包括3層，即高層：軟件質量需求評價準則（SQRC）；中層：軟件質量設計評價準則（SQDC）；低層：軟件質量度量評價準則（SQMC）。

描述和評價軟件質量的一組屬性 功能性、可靠性、易用性、效率性、可維護性、可移植性等質量特性以及將質量特性細化產生的副特性

衡量標準的組合反映某一軟件質量要素 精確性、穩健性、安全性、通信有效性、處理有效性、設備有效性、可操作性、培訓性、完備性、一致性、可追蹤性、可見性、硬件系統無關性、軟件系統無關性、可擴充性、公用性、模塊性、清晰性、自描述性、簡單性、結構性、文件完備性等

可由各使用單位自定義 根據軟件的需求分析、概要設計、詳細設計、編碼、測試、確認、維護與使用等階段，針對每一個階段制定問卷表，以此實現軟件開發過程的質量度量

表7-3軟件質量度量FCM模型

凱悦（Lawrence E. Hyatt）和羅森貝克（Linda H. Rosenberg）在《識別項目風險以及評價軟件質量的軟件質量模型與度量》（A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality）中比較了這3種最常用的軟件質量模型，其基本情況如表5-14所示。

度量標準/目標 麥 考 爾 勃 姆 ISO 9126

正確性（Correctness） X X 可維護性

可靠性（Reliability） X X X

完整性（Integrity） X X

可用性（Usability） X X X

效率性（Efficiency） X X X

可維護性（Maintainability） X X X

可測試性（Testability） X 可維護性

互操作性（Interoperability） X

適應性（Flexibility） X X

可重用性（Reusability） X X

可移植性（Portability） X X X

明確性（Clarity） X

可變更性（Modifiability） X 可維護性

文檔化（Documentation） X

恢復力（Resilience） X

易懂性（Understandability） X

有效性（Validity） X 可維護性

功能性（Functionality） X

普遍性（Generality） X

經濟性（Economy） X

表7-4 3種軟件質量模型之比較

軟件質量度量方法

軟件質量度量方法比較多，例如：（1）Halstead複雜性度量法，基本思路是根據程序中可執行代碼行的操作符和操作數的數量來計算程序的複雜性。操作符和操作數的量越大，程序結構就越複雜。（2）McCabe複雜性度量法，其基本思想是程序的複雜性很大程度上取決於程序控制流的複雜性，單一的順序程序結構最簡單，循環和選擇所構成的環路越多，程序就越複雜。

過程度量是對軟件開發過程的各個方面進行度量，目的在於預測過程的未來性能，減少過程結果的偏差，對軟件過程的行為進行目標管理，為過程控制、過程評價持續改善提供定量性基礎。過程度量與軟件開發流程密切相關，具有戰略性意義。軟件過程質量的好壞會直接影響軟件產品質量的好壞，度量並評估過程、提高過程成熟度可以改進產品質量。相反，度量並評估軟件產品質量會為提高軟件過程質量提供必要的反饋和依據。過程度量與軟件過程的成熟度密切相關。

弗羅哈克（William A.Florac）、帕克（Robert E.Park）和卡爾頓（Anita D.Carleton）在《實用軟件度量：過程管理和改善之度量》（Practical Software Measurement：Measuring for Process Management and Improvement）中描述了過程管理和項目管理的關係。認為軟件項目團隊生產產品基於三大要素：產品需求、項目計劃和已定義軟件過程。度量數據在項目管理中將被用來：（1）識別和描述需求，（2）準備能夠實現目標的計劃，（3）執行計劃，（4）跟蹤基於項目計劃目標的工作執行狀態和進展。而過程管理也能使用相同的數據和相關度量來控制和改善軟件過程本身。這就意味着，軟件組織能使用建構和維持度量活動的共同框架來為過程管理和項目管理兩大管理功能提供數據。

軟件過程管理包括定義過程、計劃度量、執行軟件過程、應用度量、控制過程和改善過程，其中計劃度量和應用度量是軟件過程管理中的重要步驟，也是軟件過程度量的核心內容。計劃度量建立在對已定義軟件過程的理解之上，產品、過程、資源的相關事項和屬性已經被識別，收集和使用度量以進行過程性能跟蹤的規定都被集成到軟件過程之中。應用度量通過過程度量將執行軟件過程所獲得的數據，以及通過產品度量將產品相關數據用來控制和改善軟件過程。

軟件過程度量主要包括三大方面的內容，一是成熟度度量（maturity metrics），主要包括組織度量、資源度量、培訓度量、文檔標準化度量、數據管理與分析度量、過程質量度量等等；二是管理度量（management metrics），主要包括項目管理度量（如里程碑管理度量、風險度量、作業流程度量、控制度量、管理數據庫度量等）、質量管理度量（如質量審查度量、質量測試度量、質量保證度量等）、配置管理度量（如式樣變更控制度量、版本管理控制度量等）；三是生命週期度量（life cycle metrics），主要包括問題定義度量、需求分析度量、設計度量、製造度量、維護度量等。

軟件過程的度量，需要按照已經明確定義的度量流程加以實施，這樣能使軟件過程度量作業具有可控制性和可跟蹤性，從而提高度量的有效性。軟件過程度量的一般流程主要包括：確認過程問題；收集過程數據；分析過程數據；解釋過程數據；彙報過程分析；提出過程建議；實施過程行動；實施監督和控制。這一度量過程的流程質量能保證軟件過程度量獲得有關軟件過程的數據和問題，並進而對軟件過程實施改善。

軟件度量相關國家標準有《DB37/T 2791-2016 軟件測試成本度量基本方法》《SJ/T 11463-2013 軟件研發成本度量規範》《GB/T 36964-2018 軟件工程 軟件開發成本度量規範》《GB/T 28827.7-2022 信息技術服務 運行維護 第7部分：成本度量規範》《GB/T 32911-2016 軟件測試成本度量規範》。 ^[2]