缺陷分析之缺陷預防的過程

在研發過程中,使用缺陷預防的策略是一個很複雜的過程,關於缺陷預防的具體過程,如圖所示。
在這裏插入圖片描述
整個缺陷預防策略的詳細步驟說明如下:
第一步:項目進行研發,研發的過程主要包括需求管理、設計和編碼三個階段,這裏統稱爲研發階段,因爲在分析缺陷預防時,研發的階段沒必要分的那麼仔細。
第二步:在測試過程中就會發現一些缺陷,此時就需要記錄這些缺陷並對缺陷進行跟蹤,現在主要是通過缺陷管理工具來對這些缺陷進行記錄和跟蹤。
第三步:記錄的問題會被收集到缺陷數據庫中,同時可以對這些問題進行分析,分析這些缺陷出現的原因和解決的情況。
第四步:對缺陷分佈的趨勢和原因進行深入的分析,分析的目的是找到現階段研發存在的問題。
第五步:階段過分析過程找到改進的方法,進而對現在的研發流程進行改進。
需要注意的是,在分析過程中其實是很難一次就改進完成,可能需要多輪的分析與改進。
在使用DP策略時,管理層必須在組織層和項目層進行一些書面的說明,當然這類書面說明又包括幾方面的內容:長期的一個資金計劃、資源和DP活動組織相關的內部管理。
在實施DP之前,需要對DP項目成員進行培訓,培訓主要包括軟件保證、配置管理、文檔支持和DP中常見的主要的統計方法。
在整個DP活動過程中,應該定期的檢查DP團隊溝通和協調的事項,評審過程中,通常需要確定以下幾個方面的內容:
Ø 引入缺陷的原因;
Ø 缺陷的影響;
Ø 預防缺陷所花費的改進成本;
Ø 對軟件質量的預期影響;
具體的關於缺陷預防和分析的步驟如下:

  1. 數據文件與度量
    數據文件是整個缺陷分析最基礎的工作,如果沒有一個數據文件來支撐,那麼就無法對缺陷進行詳細的分析。通常缺陷的數據會被集中記錄在一個存儲庫中,在一些成熟的公司是有專門的缺陷分析管理工具,這和我們現在用的缺陷管理工具可能還會有所不同,這樣可以方便DP團隊對缺陷進行跟蹤和分析。通過缺陷分析管理系統可以詳細的看到缺陷的細節和開發修改的計劃或建議。這個分析系統還會記錄缺陷修復成本與時間的關係,以及如果這個缺陷最後不被修復後所帶來的風險。
    在對缺陷進行度量時,需要定期組織缺陷預防活動的審查,這樣的目的是更好的幫助管理人員去判斷缺陷預防的情況。當然關於審查或評審的時間應該是由組織來決定,當然有可能這個時間會很長,當能這個過程中應該存在處理異常的機制,如果出現異常應該有方法可以處理。在評審時評審需要關注內容包括:主要缺陷、缺陷的分類和缺陷分析的頻率。
    此外,相關的管理層應該評審CP策略的成效,記錄活動的一些屬性,缺陷實際修復的成本和預計的成本。對活動的有效性進行驗證,是確保缺陷預防策略成功的有效途徑。
  2. 案例研究分析
    在第一步我們收集了整個分析過程中的一些數據,也就是做成了數據倉庫,並對這些數據進行分析和度量,完成這些之後,應該實時的對這些案例數據進行分析,這是整個缺陷預防中一個最重要的步驟。案例分析的方法就是常用的缺陷分析方法,關於常用的缺陷分析方法在7.6節中進行了詳細的介紹。
  3. 基準線
    在對以前的項目進行分析時,需要對已分析的數據創建一個參考基線,這個參考基線主要是用於對其它項目進行分析時參考用的,包括很多的缺陷分析方法其實都應該有一個參考值,否則很難對數據進行分析。
    在對數據進行分析時,應該對數據進行分類,就如ODC缺陷分析法其實就是從不同維度對缺陷進行分析,也就是從不同的分類角度來對缺陷進行分析。分析時按研發階段從5個階段進行分析,研發的5個階段包括:需求分析、系統設計、詳細設計、編碼和系統測試。一般情況下對缺陷從10大類的角度進行分析,並且將每個分類劃分爲三級,這個就可以用一個4位數來表示每類缺陷,通常缺陷的10個分類與說明見表:
    在這裏插入圖片描述
    上面只是對缺陷進行簡單的分類,但這個分類還是太大了,不足以找到預防的方法,所以需要對缺陷進行再次挖掘,找到更深層次的原因,這樣才能更好的定位引起缺陷的原因,下面以分析需求爲例,對需求引起的缺陷進行詳細的分析。
    下面是一個項目的實際數據,按上面的10大類對缺陷進行分類,分類後的缺陷分佈見表。
    在這裏插入圖片描述
    現在對上面10大類的的缺陷中的需求類的缺陷進行第二次挖掘,主要從四個方面對需求的缺陷進行分析:需求的完整性、需求的演示、需求變更和需求的正確性四個維度。分類後的缺陷分佈見表。
    在這裏插入圖片描述
    下面對需求的完整性進行第三次挖掘,分析由於什麼原因影響需求完整性,主要從三個維度進行分析:需求不完整、丟失或未指定的需求、過於廣義的需求,分類後的缺陷分佈見表。
    在這裏插入圖片描述
    之所以需要對缺陷進行多次挖掘的目的是找到缺陷分佈的根本原因,上面只是針對需求進行了分析,接下來使用同樣的方法對其它的維度進行分析。
    當每個維度的內容都經過深度挖掘和分析後,接下來就可以根據根本原因分析法找到改進的方法或過程,以防止下一版本出現類似的缺陷,當然對於常見的缺陷類型顯然在我們關注時優先級是最高的。在DP分析過程中將DP預防的會議或相關培訓灌輸到研發階段中,並且需要對缺陷進行記錄和度量,以確定預防措施是否生效。
    最後一步是分析改進後缺陷分佈的情況,並和改進前的缺陷分佈進行比較,以確定缺陷預防策略的有效性,之後將預防策略寫入到公司的標準流程體系中,之後再次對缺陷進行分析,如此不斷的循環,不斷的完善OSSP標準流程,這樣缺陷預防的策略就會越來越有效。
  4. 期望結果
    期望結果是指當我們不斷改進缺陷預防策略時,必須將這些預防的策略建立成一套標準流程並且列出每個階段預防策略的檢查點,形成規範文章。
    需要完善的策略主要包括以下內容:
    Ø 應該有一套方法對需求文檔中的需求進行編號;
    Ø 在描述需求時應該有一套方法來降低二義性的需求出現;
    Ø 將公用的支持和實施提取爲策略;
    Ø 改進軟件需求規格說明書的模板;
    Ø 在需求階段應該使用上下文的方式來表達,在設計階段應該使用功能接口或界面的方式來表達;
    Ø 在研發的所有階段,改進每個階段檢查點清單;
    Ø 制定原因分析的策略和會議討論或評審策略;
    Ø 測試應該有一套策略;
    如何評估缺陷預防策略的質量呢?一般從以下四個維度來評估:
    Ø 在研發過程中,每個階段總的缺陷數減少;
    Ø 研發的各個階段的缺陷分佈轉變,即前期發現的缺陷數佔總缺陷數的比例增多;
    Ø 開發的成本降低;
    Ø 開發的週期縮短。
  5. 改進策略的成果 通過上面的分析可以找到缺陷預防的改進策略,但這些改進策略必須應用到整個研發過程中去,這樣才能達到真正意義上的對缺陷進行預防。 在項目開始時,在研發的每一個階段都需要舉行相關的會議,來表達預防缺陷和因果分析的重要性,並且在每個階段評審時應該有相應的檢查清單,在進行同行評審時,應該對照這些檢查清單來評審。 在整個研發過程中,每個階段都應該使用缺陷跟蹤系統詳細記錄缺陷並對其原因進行分析,現在很多公司都有自己的缺陷管理系統,將缺陷記錄在缺陷管理系統中,這樣可以更好的跟蹤缺陷解決的方法和缺陷從開始記錄到處理結束後的整個解決過程。 在對缺陷進行原因分析時,缺陷的解決方案必須是要讓人滿意的,並且通過會議來討論,這樣可以讓大家在整個過程中,對缺陷的預防和改進有一個較好的理解。 以上是缺陷預防的5個步驟,核心步驟還是缺陷分析和改進流程的確定。