根本原因缺陷分析法

2021-10-16 17:50:37 字數 1719 閱讀 8092

軟體缺陷管理過程不僅包含軟體缺陷記錄和統計,更重要的是對缺陷資料進行細緻、深入的分析。缺陷分析是缺陷管理中的乙個重要環節,有效的缺陷分析不僅可以評價軟體質量,同時可以幫助專案組很好地掌握和評估軟體的研發過程,進而改進研發過程,未對缺陷進行分析就無法對研發流程進行改進。此外,還能為軟體新版本的開發提供寶貴的經驗,進而在專案開展之前,制定準確、有效的專案控制計畫,為開發高質量的軟體產品提供保障。

常用的缺陷分析方法有:根本原因缺陷分析法、四象限缺陷分析法、odc 缺陷分析法、rayleigh缺陷分析法和gompertz 缺陷分析法。

本節我們來學習下根本原因缺陷分析法。

根本原因分析(root cause analysis,rca)是一種產品質量管理工具,但現在不僅僅用於對產品質量的管理,在很多領域對問題原因進行分析時都用到該工具。rca 可以簡單地定義為:使用結構化的過程和方法,識別問題產生的根本原因並制定相應的解決方案,使問題不再發生。根本原因(root cause)是指導致問題發生的最基本原因,與直接原因和表面原因不同的是,根本原因可防止問題的再次發生,一般乙個根本原因與一組或一類問題相關,而不是僅僅侷限於某個問題。

rca 過程包括四個階段:收集資訊、理解問題、確定根本原因和制定解決方案。如圖9-7 所示。

rca 在分析時採用一些特定的方法和工具,常用的方法有魚骨圖、關係圖(interrelationshipdiagram)、當前現實樹(current reality tree)等,本節在後面的內容中主要介紹魚骨圖法如何分析系統缺陷。

1953 年,日本管理大師石川馨先生提出一種把握結果(特性)與原因(影響特性的要因)的極方便而有效的方法,故名「石川圖」。因其形狀很像魚骨,是一種發現問題「根本原因」的方法,是一種透過現象看本質的分析方法,也稱為「魚骨圖」(cause & effect/fishbone diagram)或者「魚刺圖」。

魚骨圖分析法的步驟如下:

(1)決定問題特性。

問題特性即需要解決的問題,如圖9-8 所示。

(2)特性和主骨。

(3)大骨和根本原因。

大骨上分類書寫3~6 個根本原因,用方框框起來,如圖9-9 所示。

特性寫在右端,用方框框起來,主骨用粗線畫,加箭頭標識,如圖9-10 所示。

大骨通常採用6m 方法:人力(manpower)、環境(mother-nature)、機械(machinery)、測量(measurement)、方法(methods)和物料(materials)。6m 常規圖如圖9-11 所示。

(4)中骨、小骨、孫骨。

中骨是闡明事實,小骨要圍繞「為什麼會那樣」來寫,孫骨要更進一步來追查「為什麼會那樣」。

(5)記錄中骨、小骨、孫骨的「要點」。

(6)深究要因。

(7)記入關聯事項。

軟體缺陷分析過程中,根本原因主要從四個方面來考慮:開發階段相關(phase-related)、人員相關(human-related)、專案相關(project-related)和複審相關(review-related)。軟體缺陷根本原因分析圖如圖9-12 所示。

【例項】系統中包含乙個採集資料的模組,在測試過程中發現該模組偶爾出現資料採集中斷的現象,但一直沒有找到具體的原因。在發布前缺陷評審時,該缺陷也通過評審,允許發布,但發布到市場後,大量客戶反饋該問題,之後研發團隊才開始重視該問題,對該問題進行詳細分析。分析發現選擇的中斷處理方式不是最優的,當前使用的中斷方式存在缺陷。通過魚骨圖對該缺陷產生的原因進行分析,如圖9-13 所示,其主要的原因有兩個:一是該方案在設計時並未經過任何審核;二是開發工程師經驗缺乏,錯誤地認為設計的中斷方案是最優的。

「改革」失敗的根本原因

現在總算體會到 改革 的艱辛了 而跟以前的大多數 改革 者不同的是 我不會用性命去堅持 因為我知道那樣是沒有意義的 老古董啊老古董 這樣做方便,這樣做省事 已經這樣做了 這些可以稱之為原因麼?始終無法說服我 改革 失敗的原因 除了 改革 者本來的能力和準備外 最最主要的是有兩類人存在 部分人的中立和...

軟體公司加班的根本原因

軟體公司加班,這應該是個很尋常的事情 其實加班不應該是乙個感到不舒服的事情,任何公司或單位都會加班,只是程度不同而已,程度才決定了算不算舒服。加班不一定是壞事,看是什麼情形。為什麼會加班呢 加班一般是沒做完事情的直接結果。但是可能有兩種可能,一種是應該完成的事情沒有完成導致的 另一種即是一些特殊情況...

軟體開發問題的症狀及其根本原因

症狀 對終端使用者的需求理解的不夠精確 對需求的改變束手無策 程式塊不相容 軟體不易維護或不易擴充套件 對專案嚴重缺陷的發現較晚 軟體質量低劣 軟體效能無法令人接受 開發組中的人員按各自的方式進行開發,如果有人改變了部分軟體,將很難再進行重組 乙個不可靠的構造和發布過程 原因 特別的需求管理 模糊和...