ODC缺陷分析法
軟件缺陷管理過程不僅包含軟件缺陷記錄和統計，更重要的是對缺陷數據進行細緻、深入的分析。缺陷分析是缺陷管理中的一個重要環節，有效的缺陷分析不僅可以評價軟件質量，同時可以幫助項目組很好地掌握和評估軟件的研發過程，進而改進研發過程，未對缺陷進行分析就無法對研發流程進行改進。此外，還能為軟件新版本的開發提供寶貴的經驗，進而在項目開展之前，制定準確、有效的項目控制計劃，為開發高質量的軟件產品提供保障。
常用的缺陷分析方法有：根本原因缺陷分析法、四象限缺陷分析法、ODC 缺陷分析法、Rayleigh缺陷分析法和Gompertz 缺陷分析法。
本節我們來學習下ODC缺陷分析法。
ODC(Orthogonal Defect Classification，正交缺陷分類)是獲取缺陷的一種分類方案，但它不僅僅是一個分類方案，還是一個軟件過程的度量系統，它是建立在包含於缺陷流中的語義信息基礎上的，可以幫助評估測試效率，對錯誤進行跟蹤，通過方案的分析機制可以評估客戶的滿意度。
1990 年Ram Chillarege 博士等人提出ODC 概念，並於1997 年基本完成ODC 理論體系建設。1998 年以後，IBM 公司開始在其全球24 個研發機構推廣該技術，並取得了很好的經濟效益。
ODC 一共有8 個屬性，如圖9-17 所示。當測試工程師發現缺陷並進行提交時，可以為該缺陷分配“活動(Activity)”“觸發(Trigger)”和“影響(Impact)”三個屬性;開發工程師在修改缺陷時，可以為該缺陷分配“階段(Age)”“來源(Source)”“限定符(Qualifier)”“類型(Type)”和“目標(Target)”五個屬性。
活動(Activity)：是指當前缺陷被發現時的實際操作步驟(如代碼審查、功能測試等)。
觸發(Trigger)：描述暴露該缺陷時系統的環境或引發的條件。
影響(Impact)：該缺陷給用戶帶來哪些方面的影響。
階段(Age)：缺陷是由新代碼還是重寫的代碼引起的。
來源(Source)：缺陷出現在內部代碼、重用庫代碼、移植代碼還是外包代碼。
限定符(Qualifier)：定義引起缺陷的原因。
類型(Type)：定義缺陷的類型，如算法、初始化等。
目標(Target)：將在哪裡改正錯誤，如設計、代碼等。
ODC 的生命週期包括三種可能的角色、三種可能的循環和六大實施步驟。
(1)ODC 實施中可能的三種角色
團隊成員：團隊成員包括開發工程師、測試工程師、用戶。
ODC 負責人：ODC 負責人必須熟悉ODC 分類的執行，需要制定ODC 實施計劃，指導團隊成員進行ODC 分析。
ODC 特別小組：ODC 特別小組由開發工程師、測試工程師的代表組成，主要負責制定行動計劃、確認錄入數據的正確性和進行ODC 分析。
(2)根據ODC 所需步驟的數量，有三種可能的循環
大循環：除了預備步驟，該循環本身包含五個步驟。
中等循環：包含四個步驟，包含ODC 生命週期的核心組成部分，儘管無法進行完整的ODC 分析，但仍然可以執行一些有用的評估。
小循環：只包含兩個步驟，只要找到一定數量的缺陷，隨時可能發生確認的活動。
(3)ODC 包含以下六大步驟
1)預備階段。獲得主管的批准和支持來實施ODC 方法，獲得開發團隊和測試團隊的支持，確定一個ODC 負責人，由負責人來提供培訓和指導，分析項目當前狀態，確定ODC 特別小組，由開發工程師和測試工程師代表組成。
2)計劃。需要把項目分成多個組件，每個缺陷都將追蹤到相關組件，以供將來分析用，組件的劃分可以按照功能名稱、物理分佈或邏輯關係來確定。確定ODC 分析的時間點，ODC 分析可以在功能測試和用戶驗收測試之後進行，ODC 分析時間點的選擇將直接影響後續質量改進的成效。對於迭代的開發流程，可以在每個迭代結束的時候進行ODC 分析。
3)數據錄入。在數據錄入之前，應該確保所有的開發工程師和測試工程師清楚地理解每一個缺陷的含義。
4)數據確認。在數據錄入之後，需要進行確認工作來保證錄入數據的正確性。
5)分析。收集好一定的數據之後，即可以通過各種統計圖表來分析這些數據，分析工作可以在項目開發週期的任何時間點進行，通過統計圖表分析出影響質量的原因。
6)行動。制定一個正式的行動計劃來幫助我們持續地提高產品質量，行動計劃可以是針對設計文檔、源代碼、開發流程、測試方法等進行改進的建議，行動計劃定義必須清晰且可度量。
ODC 模型如圖9-18 所示。
ODC 分析案例1：使用ODC 評估設計、代碼的充分性。
首先從缺陷類型的角度來分析缺陷與設計相關的問題，按分配、校驗、設計方法、接口、編輯和打包幾個維度對缺陷類型進行分類，如圖9-19 所示。
從圖9-19 中可以看出設計方法的問題較多，說明系統設計的水平應該再提高。接下來，在該圖基礎上可以從限定符維度對設計方法引入的缺陷進行詳細的分析，從不同的角度來分析每種缺陷類型的數量。我們設置三種限定符：錯誤的(Incorrect)、丟失的(Missing)以及外來的(Extraneous)，如圖9-20 所示。錯誤的表示代碼存在，編寫不正確;丟失的表示代碼本應該有的，但開發工程師遺漏了。
從圖9-20 中可以看出，大多數缺陷是由代碼錯誤引起的，說明我們的代碼寫得太糟糕，如果該案例丟失的缺陷很多，說明詳細設計說明書做得不夠好。ODC 分析案例2：使用ODC 分析缺陷對客戶的影響。
從缺陷影響的角度對缺陷進行分析，ODC 從可安裝性、安全性、性能、易維護性、易操作性、易移植性、文檔、易用性、標準符合性、可靠性、易獲得和需求幾個方面來分析缺陷對客戶的影響。ODC 分析圖如圖9-21 所示。
從圖9-21 中可以看出，該產品問題主要集中在性能、易維護性和易用性方面，如果產品這樣上市是很可怕的，必須採取相應的措施來完善這幾個方面的問題。
ODC 分析案例3：ODC 評估缺陷修復效率。
在測試過程中有時會發現測試時間被延遲，通過ODC 按缺陷嚴重等級的屬性可以分析每類缺陷修復的時間。通過描繪缺陷嚴重等級與修改缺陷的時間圖，來分析修復缺陷所花費的時間，如圖9-22 所示。
從圖9-22 中可以看出，致命缺陷和嚴重缺陷都已經修復，修復所有致命缺陷的時間為17 天，修復所有嚴重缺陷的時間為20 天。
閱讀更多 川石信息 的文章
