軟件度量包含三個維度的內容：產品設計指標度量、過程度量和項目度量。產品設計指標度量是指從產品設計角度的一些特性指標角度度量，如規模大小、複雜程度、設計特點、性能和質量水平。過程度量主要是用於提高開發和維護的效率，如開發過程中缺陷去除的效果、測試過程中的缺陷模型和修復過程的響應時間。項目度量是從項目特點和執行的角度進行度量，如開發商數量、生命週期、成本、進度等。
一、缺陷密度度量
缺陷密度也就是平常所說的缺陷率，缺陷率看似很簡單，但是如果我們不能討論清楚缺陷率中分子與分母的值，那麼就不可能很好地確定缺陷率的概念。一般缺陷率的概念是指一個特定的時間幀中缺陷出現的機會。
分母通常指的是軟件的大小，通常使用千萬代碼(KLOC)或功能數來形容。時間幀是指產品生命期中的一系列操作，生命期少則一年，多則幾年，通常95%的缺陷會在產品發佈的四年之內發現，而絕大多數數據缺陷通常是在兩年內被發現。
千行代碼這個度量其實很簡單，主要的問題是如何精確地計數實際的代碼行數，在早期的彙編語言中，一行物理代碼就相當於我們要計數的一行代碼，但在高級語言中可能就不會這樣，一行物理行並不一定是一行代碼，即使同一個代碼片段使用不同的計數工具計數，也可能導致結果存在差異，通常統計代碼行有以下幾種方法：
1)只統計可執行的行代碼;
2)只統計帶數據定義的可執行的行代碼;
3)統計可執行行代碼、數據定義和註釋;
4)統計可執行行代碼、數據定義、註釋和控制語句;
5)統計在輸入屏幕中做為物理行的代碼;
6)統計做為邏輯分隔符的終止行代碼;
上面是常見的關於代碼行的統計方法，不同的公司可能會有著不同的統計方法，但不管使用什麼方法進行統計，統計的方法只能使用一種。不同的項目使用不同的統計方法，這樣數據之間沒有參考價值。
通常說的代碼是程序文件中的一行代碼，但是註釋行或空行除外，代碼通常包括程序頭、函數聲明、可執行的語句和不可執行的語句。
在統計過程中，統計物理行代碼和統計指令語句是存在差異的，有時候甚至會差得很多，如Basic、Pascal 和C 語言，在一行物理行上就可能出現多個指令。另一方面，一條指令語句和數據聲明也可能跨越幾條物理行代碼，特別是在編程時，如果為了維護方便，寫代碼時就很容易出現這種問題。使用邏輯行和物理行進行統計各有優缺點，但是可能邏輯行來統計代碼行會更合理一些。
例如：某個項目，通常代碼行總數由邏輯行代碼、可執行代碼和相關數據定義的代碼組成，但不包含註釋代碼。代碼行的總數應該由產品所有的代碼和新版本所新增加的或修改的代碼組成。源有的代碼語句稱之為SSI，新增的和修改的稱之為CSI，SSI 與CSI 公式如下：
SSI(當前版本)= SSI(以前的版本)+ CSI(當前版本新增或修改的代碼行)
− 刪除的代碼(一般這個值很小)
− 修改的代碼(不能在SSI 和CSI 中計算兩次)
產品發佈後需要對缺陷進行跟蹤，在跟蹤缺陷過程中可以對缺陷進行分類，通常分為用戶發現和內部缺陷兩類，每千行SSI 和每千行CSI 主要度量的內容如下：
(1)每千行缺陷率主要用來度量產品代碼質量的。
(2)從不同類型的角度統計千行缺陷率，這主要用來度量不同類型所發現的缺陷總數。
(3)新修改或增加的每千行代碼所發現的缺陷數。
(4)由客戶所發現的，新新修或增加的每千行代碼缺陷數。
產品發佈後需要對缺陷進行跟蹤，在跟蹤缺陷過程中可以對缺陷進行分類，通常分為用戶發現和內部缺陷兩類，每千行SSI 和每千行CSI 主要度量的內容如下：
第(1)點主要度量總的已發佈代碼的質量，第(3)點主要度量新修改或增加的代碼的質量，如果當前測試的版本就是發佈的第一個版本，那麼第(1)點和第(3)點表達的意思是一致的。第(1)點和第(3)點主要是針對過程進行度量的。第(2)點和第(4)點主要是從客戶的角度進行分類度量。對千行CSI 率和千行SSI 率進行估計，開發工程師可以通過修復缺將對用戶的影響降低到最小化。
二、客戶角度
缺陷率是度量軟件質量的一個基礎單元，但從開發團隊的角度來說，通過對缺陷率的分析可以有效地提高產品的質量。從實踐的角度來說，一個好的軟件質量需要從用戶的角度來分析。如果以缺陷率來做產品發佈時產品質量的度量，那麼從客戶角度，缺陷率並一定直接決定缺陷的總數。所以一個好的缺陷率應該是會讓發佈產品的總缺陷數下降。如果一個新發布的版本比較以前版本的代碼量更大，這就說明新添加的修改的代碼的缺陷率要下降，這樣才能更好的降低缺陷的總數。
例如：
第一個版本發佈時的數據如下：
KSSI=60 KLOC
由於第一個版本，KCSI 的值正好等於KSSI 的值，所以KCSI=KKSI=60 KLOC
統計出來的缺陷率為：缺陷/千行代碼=2.0
總的缺陷數為120 個。
第二個版本發佈時的數據如下：
假設新增加代碼量為20 千行，即KCSI=20KLOC
KSSI=60(上一版本總代碼數)+20(新添加或新修改的代碼數)
-4(假設新添加或新修改的代碼數中，假設有20%是修改原來的代碼)
= 76
統計出來的缺陷率為：缺陷/千行代碼=1.8(假設相對於第一個版本提高了10%)
第二個版本總增加的缺陷數為1.8×20=36。
第三個版本發佈時的數據如下：
假設新增加代碼量為30 千行，即KCSI=30KLOC
KSSI=76(上一版本總代碼數)+30(新添加或新修改的代碼數)
-6(假設新添加或新修改的代碼數中，假設有20%是修改原來的代碼)
= 100
第三個版本總增加的缺陷數為38
缺陷/千行代碼=39/30=1/3
第一個版本發現了100 個BUG，第二個版本發現了36 個BUG，用戶直觀感受是缺陷下降了64%((100-36)/100)，當然這主要是因為第二版本新增或修改的代碼量下降了。第三個版本的缺陷又大於第二個版本的缺陷數，這是因為第三個版本新增或修改的代碼量比第二個版本多出很多，但缺陷率就下降了很多，第二個版本是1.8，第三個版本是1.3，缺陷率大概為第二版本的三分之一。當然第二個版本和第三個版本缺陷率差異太大，這樣可能測試中很難達到這樣一個值，這種情況下必須對計劃、代碼進行改進。
三、功能點
上面介紹的是通過代碼行的方式來度量缺陷，除了這種方式外，另外一種度量方式是通過功能點的方式來度量，這兩種方式都是通過缺陷密度來表達系統出錯的可能性。在近些年通過功能點來度量的方式越來越被人接受，可以從兩個方面來度量：開發工程師的工作效率(如每人每年開發了多少功能點)和系統質量(如平均每個功能點所發現的缺陷數)。
一個功能是指一個可執行語句的集合，這些語句是用來執行某項工作任務的，其包括參數、本地變量和聲明語句。使用功能點度量開發工程師工作效率時，只關注功能點的多少，而不需要關注代碼行數。使用功能點度量缺陷，即關注每個功能點的缺陷分佈情況，如果單位功能點缺陷率比較低，那麼通常說明產品的質量比較高，即使這個時候KLOC 缺陷率比較高，但是如果一個功能點其實現的代碼數很少，這樣使用功能點去度量就可能會變得很困難。
功能度量最好是在IBM 公司開始使用，但由於當時的技術並不能很好地對功能進行準確的度量，所以使用功能進行度量時出現一個失誤的地方。使用功能點解決了生產率和代碼行數的問題，因為在統計代碼行時，有很多不確定的因素，特別是不同的語言其統計的結果可能差異比較大。在我們定義一個應用時，應該從五個方面來加權評估：
(1)如果是外部輸入(如交易類型功能)，權重為4。
(2)如果是外部輸出(如報告類型)，權重為5。
(3)內部邏輯文件，權重為10。
(4)外部接口文件，權重為7。
(5)外部查詢數，權重為4。
上面是平均加權的方式，還一種是低複雜度和高複雜度的加權，具體如下：
(1)如果是外部輸入(如交易類型功能)，低複雜度權重為3，高複雜度權重為6。
(2)如果是外部輸出(如報告類型)，低複雜度權重為4，高複雜度權重為7。
(3)內部邏輯文件，低複雜度權重為7，高複雜度權重為15。
(4)外部接口文件，低複雜度權重為5，高複雜度權重為10。
(5)外部查詢數，低複雜度權重為3，高複雜度權重為6。
組件複雜度的確定也是很難的，在確定這些組件複雜度時，需要有一些標準的準則。例如，如果數據元素的類型超過20 種，涉及的文件類型超過2 個，這種情況複雜度為高;如果數據元素的類型少於5 種，涉及的文件類型超過2 個或3 個，這種情況複雜度為低。
功能點總數的公式如下：
1)數據通信;
2)函數分佈;
3)性能;
4)使用配置;
5)交易率;
6)聯機數據輸入;
7)終端用戶使用效率;
8)在線更新;
9)複雜的過程;
10)可重用性;
11)安裝的易用性;
12)操作的易用性;
13)多站點訪問;
14)改變的方便性。
這些特性的權值範圍是0～5，通過下面的公式可以對特性的因子進行調整，具體的公式如下：
閱讀更多 川石信息 的文章
