軟體質量度量



軟體度量可以分為三類:

  • 產品度量 - 描述產品的特性,例如大小、複雜性、設計特性、效能和質量水平。

  • 過程度量 - 這些特性可用於改進軟體的開發和維護活動。

  • 專案度量 - 此度量描述專案特徵和執行情況。例如,軟體開發人員的數量、軟體生命週期內的員工配置模式、成本、進度和生產率。

某些度量屬於多個類別。例如,專案的在製品質量度量既是過程度量也是專案度量。

軟體質量度量是軟體度量的一個子集,它關注產品、過程和專案的質量方面。它們與過程和產品度量比與專案度量更密切相關。

軟體質量度量可以進一步細分為三類:

  • 產品質量度量
  • 在製品質量度量
  • 維護質量度量

產品質量度量

這些度量包括以下內容:

  • 平均故障間隔時間(MTBF)
  • 缺陷密度
  • 客戶問題
  • 客戶滿意度

平均故障間隔時間(MTBF)

它是故障之間的時間。此度量主要用於安全關鍵系統,例如航空交通管制系統、航空電子裝置和武器。

缺陷密度

它衡量相對於軟體大小(以程式碼行數或功能點等表示)的缺陷,即衡量單位程式碼質量。此度量用於許多商業軟體系統。

客戶問題

它衡量客戶在使用產品時遇到的問題。它包含客戶對軟體問題空間的看法,其中包括非缺陷導向問題以及缺陷問題。

問題度量通常以每使用者月問題數 (PUM)表示。

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

其中,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM 通常在軟體釋出到市場後的每個月計算,以及按年計算月平均值。

客戶滿意度

客戶滿意度通常透過五點量表透過客戶調查資料進行衡量:

  • 非常滿意
  • 滿意
  • 中立
  • 不滿意
  • 非常不滿意

對產品整體質量及其特定維度的滿意度通常透過各種客戶調查方法獲得。根據五點量表資料,可以構建和使用幾個略有不同的度量,具體取決於分析的目的。例如:

  • 完全滿意客戶的百分比
  • 滿意客戶的百分比
  • 不滿意客戶的百分比
  • 不滿意客戶的百分比

通常,使用此百分比滿意度。

在製品質量度量

在製品質量度量處理在某些組織的正式機器測試期間缺陷到達情況的跟蹤。此度量包括:

  • 機器測試期間的缺陷密度
  • 機器測試期間的缺陷到達模式
  • 基於階段的缺陷去除模式
  • 缺陷去除有效性

機器測試期間的缺陷密度

正式機器測試(程式碼整合到系統庫後進行的測試)期間的缺陷率與現場的缺陷率相關。測試期間發現的較高缺陷率表明軟體在其開發過程中經歷了更高的錯誤注入,除非較高的測試缺陷率是由於非同尋常的測試工作量造成的。

每千行程式碼或功能點的這個簡單的缺陷度量是一個很好的質量指標,而軟體仍在測試中。它對於監視同一開發組織中產品的後續版本特別有用。

機器測試期間的缺陷到達模式

測試期間的整體缺陷密度只會提供缺陷的摘要。缺陷到達模式提供了有關現場不同質量水平的更多資訊。它包括以下內容:

  • 按時間間隔(例如,周)報告的測試階段的缺陷到達或缺陷。這裡所有這些都不會是有效的缺陷。

  • 在對報告的問題進行問題確定時,有效缺陷到達的模式。這是真正的缺陷模式。

  • 缺陷積壓隨時間的變化模式。需要此度量,因為開發組織無法立即調查和修復所有報告的問題。這既是工作量陳述也是質量陳述。如果在開發週期結束時缺陷積壓很大,並且許多修復尚未整合到系統中,則系統的穩定性(因此其質量)將受到影響。需要重新測試(迴歸測試)以確保達到目標產品質量水平。

基於階段的缺陷去除模式

這是測試期間缺陷密度度量的擴充套件。除了測試之外,它還跟蹤開發週期所有階段的缺陷,包括設計評審、程式碼檢查和正式驗證(在測試之前)。

由於很大一部分程式設計缺陷與設計問題有關,因此進行正式評審或功能驗證以增強前端過程的缺陷去除能力,從而減少軟體中的錯誤。基於階段的缺陷去除模式反映了開發過程的整體缺陷去除能力。

關於設計和編碼階段的度量,除了缺陷率之外,許多開發組織還使用諸如檢查覆蓋率和檢查工作量等度量來進行在製品質量管理。

缺陷去除有效性

可以定義如下:

$$DRE = \frac{開發階段去除的缺陷}{產品中潛藏的缺陷} \times 100\%$$

可以針對整個開發過程、程式碼整合之前的前端以及每個階段計算此度量。在用於前端時稱為早期缺陷去除,在用於特定階段時稱為階段有效性。度量值越高,開發過程越有效,傳遞到下一階段或現場的缺陷越少。此度量是軟體開發缺陷去除模型的關鍵概念。

維護質量度量

儘管在此階段無法做太多事情來改變產品的質量,但以下是可以執行的修復,以便儘快消除缺陷並確保出色的修復質量。

  • 修復積壓和積壓管理指數
  • 修復響應時間和修復響應能力
  • 逾期修復百分比
  • 修復質量

修復積壓和積壓管理指數

修復積壓與缺陷到達率以及報告問題的修復變得可用的速度有關。它是每個月或每個星期末剩餘的已報告問題的簡單計數。以趨勢圖的形式使用它,此度量可以為管理維護過程提供有意義的資訊。

積壓管理指數 (BMI) 用於管理未解決問題的積壓。

$$BMI = \frac{本月關閉的問題數量}{本月到達的問題數量} \times 100\%$$

如果 BMI 大於 100,則表示積壓減少。如果 BMI 小於 100,則表示積壓增加。

修復響應時間和修復響應能力

修復響應時間度量通常計算為從開啟到關閉的所有問題的平均時間。較短的修復響應時間可以提高客戶滿意度。

修復響應能力的重要因素包括客戶期望、商定的修復時間以及履行對客戶承諾的能力。

逾期修復百分比

計算如下:

$逾期修復百分比 =$

$\frac{按嚴重程度級別超過響應時間標準的修復數量}{指定時間內交付的修復總數} \times 100\%$

修復質量

修復質量或有缺陷修復的數量是維護階段的另一個重要質量度量。如果修復沒有修復報告的問題,或者修復了原始問題但引入了新的缺陷,則該修復是有缺陷的。對於關鍵任務軟體,有缺陷的修復不利於客戶滿意度。有缺陷修復的度量是在一段時間內所有修復中出現缺陷的百分比。

可以以兩種方式記錄有缺陷的修復:在發現它的月份記錄它,或在交付修復的月份記錄它。第一個是客戶衡量標準;第二個是流程衡量標準。這兩個日期之間的差異是有缺陷修復的潛伏期。

通常,潛伏期越長,受影響的客戶就越多。如果缺陷數量很大,則百分比度量的較小值將顯示出樂觀的景象。當然,維護過程的質量目標是零有缺陷的修復,並且沒有拖延。

廣告
© . All rights reserved.