在開發新的軟件系統過程中，由於存在許多不確定因素，軟件開發失敗的風險是客觀存在的。因此，風險分析對於軟件項目管理是決定性的。風險分析實際上就是貫穿在軟件工程過程中的一系列風險管理步驟，其中包括：風險識別、風險估計、風險管理策略、風險解決和風險監督等。
要理解風險分析，我們首先要理解‘風險’這個名詞。用漢語的邏輯去對這個詞做一個通俗性解釋，可以這么展開：風險=“一個不好的事情可能會發生”。這里要注意這句話里的兩個要素：一是“可能”，即這是一種可能性的預測，他不是真實已經發生的或者100%一定發生了的事；二是“不好的事”，站在軟件產品質量的角度而言，就是質量的一個瑕疵、問題。
那么總結一下，對於軟件產品而言，產品的風險就是軟件產品可能會有質量問題的情況（更直白一點就是，產品可能會有缺陷）。
我們引用ISTQB對於產品風險定義：
在軟件或系統中的潛在失效部分（即將來可能發生不利事件或危險）稱之為產品風險，因為它們對產品質量而言是一個風險，包括：
- 故障頻發的軟件交付使用；
- 軟件/硬件對個人或公司造成潛在損害的可能性；
- 劣質的軟件特性（比如功能性、可靠性、易用性和性能等） ；
- 低劣的數據完整性和質量（例如：數據遷移問題、數據轉換問題、數據傳輸問題、違反數 據標准問題）；
- 軟件沒有實現既定的功能。
那么為什么我們研發的軟件產品會有風險存在呢？其實問這個問題就等同於問’為什么軟件產品可能會有缺陷呢‘？其實這個問題的本質就在於’人都是會犯錯誤的‘這樣一個論斷的成立。基於這個論斷我們又可以推論出：’因為人都會犯錯誤，所以人開發出來的軟件也就可能帶有錯誤‘。這些在研發過程中我們犯的錯誤，遺留在產品中，就是缺陷；缺陷存在的可能性，就是產品風險。
我們還可以更具體的去討論，哪些因素，可能導致我們研發軟件時更容易在產品中遺留錯誤：
① 產品大小/代碼量：工作量越大，那么我們就越有可能犯錯。
② 技術因素：未曾使用過的新技術都存在風險。包括未使用過的新型硬件、支持軟件，缺乏標准與規范的非傳統的開發方法等。技術過時也是風險。技術風險一般難於改正。
③ 開發環境：適用的開發工具不足、不可靠、使用不方便等因素，都會降低開發效率。
④ 組織規模和人員經驗：比如人手不足，人員經驗不豐富，都有可能帶來產品風險。
⑤ 客戶因素：表現在客戶需求經常矛盾，不了解客戶的特殊需要，客戶不了解項目中采用的新技術，且雙方又難於溝通等。
所以，既然軟件產品的風險是客觀存在的，我們就要采取必要手段對風險進行處理，於是就引出了我們今天的課題，’風險分析‘。
首先描述一下風險分析的步驟，一般而言我們可以認為風險分析包括以下部分內容：
- 風險識別 想要控制風險，我們首先要知道有哪些風險，不然談何控制？
- 風險評估 知道了有哪些風險，其次我們要判斷風險有多大，有多嚴重
- 風險緩解 知道了風險有哪些和他的嚴重程度，我們就要想辦法去緩解和規避風險
- 風險管理 最后我們要對風險進行管理，達到風控的目標
理論說了這么多，下面用一個簡單的實際例子來詮釋風險分析的過程。
我還是拿上一篇《實例！軟件缺陷數據度量和分析》中的COTS項目為例，這個項目情況是這樣的：
- 該項目為一個COTS產品的定制性二次開發項目
- 項目周期計划為4個月，實際完成時間為6個月
- 項目是一個總體人員不到10人的小型項目
- 采用持續集成，高速迭代的研發方式
第一步：列出軟件的所有功能和特性
根據項目相關人員對本項目的調研，我們列出了以下的軟件功能模塊和特性：
所有主功能：訂單支付模塊、用戶管理模塊、后台管理模塊、瀏覽展示模塊、用戶評價子系統、活動模塊、促銷管理模塊
質量專項問題：功能性問題、性能問題、界面問題、易用性問題、安全性問題、計算錯誤、描述錯誤
用表格來展示就是這樣的：
所有我們列出來的這些條目，就是所謂的“風險項目”。
那么風險識別這件事，在項目里應該由誰來做呢？一般情況下，風險分析的過程除了有專家的參與，更是一種集體智慧的體現，也就是說項目所有利益相關方，都應該參與到風險分析的過程中。在風險識別這個動作上，頭腦風暴是一種可行的方法（即與會各方各抒己見，提出自己認為產品可能有的風險項）。
第二步：對每個風險項目做出風險等級評估
在風險評估過程中，我們要對上個階段列出的風險項目做出評估，得出風險高低大小的一個排序。
這里我們要考慮風險的兩個維度：風險發生的可能性大小，以及風險如果發生，帶來的影響范圍和嚴重程度有多大。
我們首先用定性的方法對風險進行評估，采用風險評估矩陣來指導我們的評估過程：
我們將前一階段得出的風險項目列表進行兩個維度的風險判斷，得出如下結果：每一個風險項我們都從兩個維度給他’高、中、低‘的判斷：
那么這個填表過程是由誰來執行呢？答案仍然是集體智慧。風險評估會議要求各項目利益相關方參與，項目團隊的成員，包括客戶（如果可能的話）每個個體都可能在評估過程中表達自己在某一方面最權威的意見。打個比方說，上面表單里的’訂單支付模塊‘的影響范圍，最適合對他進行評估的可能就是：客戶、需求人員和測試工程師；而對於’后台管理系統‘的風險概率，最適合對他進行評估的可能是：開發組長或者對應的開發人員，以此類推。
得到這個評估表，我們使用先前的風險評估矩陣對他進行排序和整理，就得出以下結果：
進一步：
到此為止我們就完成了定性風險評估的過程。
不過這種定性分析還沒有能夠很細致的展示各風險項之間更細節的風險等級，比如上圖標注紅色，風險等級為高的三個項目，他們之間的排序我們並不能確定。
所以我們可以改為采用更為細致的一種定量分析，比如我們把’高、中、低‘這樣的指標轉換為’3，2，1‘這樣的得分系統，可以得出如下結果：
可以看到，通過得分相加（采用發生概率和影響范圍兩個指標相乘是一種更合理的做法）這樣的形式，我們得出了更為細致的風險等級划分。
實際上我們還可以更進一步細化，比如對於所有風險項的發生概率，我們可以結合其產生原因進行去量化分析：
對於風險的影響范圍，我們從相關風險的使用頻率和問題的嚴重程度去進行量化：
這樣再從兩個維度去對這個表格做一個運算，不管是用相加還是相乘的策略，我們就能得出更准確的一個風險排序。
當然風險評估除了矩陣法，還有一些其他的方法我們就不一一闡述了。
第三步：定義風險緩解措施
既然我們已經得到風險由高到底的一個風險結果，那么我們就要實施一些措施，對這些風險進行規避和緩解。
這里我們可以有很多種思路：比如將更有經驗的開發人員投入到風險高的領域里面去，或者向風險高的領域投入更多的人手，等等。
還有就是：進行基於風險的測試。
實際上，軟件測試活動，本身就可以被認為是一種風險控制措施。試想一下，我們測試團隊，對於一個軟件進行測試，發現了缺陷進行匯報，並督促開發團隊去修復和解決問題。這是不是已經直觀的降低了產品的風險？這個論斷顯然是成立的。而測試活動通過其反饋作用，去達到過程改進的效果，也可以更進一步的幫助項目去規避風險。
那么基於風險的測試應該怎么去組織呢？我們就是用風險分析的結果報告，去指導我們測試的開展，具體而言可以有如下措施：
- 基於風險確定測試優先級
- 基於風險確定測試完備性
- 基於風險確定測試資源分配
這樣的一些措施要基於我們測試的幾個基本原則：
1. “測試是不可能窮盡的” - 既然測試不可能窮盡，那么我們就應該優先去測試風險高的部分，把低的部分放到后續去做，如果時間不允許甚至有部分低風險的部分不測。
2. “缺陷具有集群性” - 即所謂的20%的模塊有80%的bug，那么我們通過將風險可能性高的部分去准備更完備的測試（比如更多的測試用例覆蓋，更多的執行輪次，更多的執行時間）和更有經驗的人員，就可以實現軟件質量的快速上升。
最后要注意：風險分析不是一個一次性的工作，我們要通過在項目實際研發過程中得到的信息和反饋，對風險等級進行調整，比如調高和調低風險等級。一個實際的例子是：我們在項目開始時，將某一個風險項目定為了高級，因此這個風險項引起了團隊的重視。而正因為團隊對這個風險項目很重視，以至於在后續工作開展過程中，團隊投入了更多的資源和力量，導致最終測試階段可能反而在這個模塊里面沒有發現太多問題，也即他真正展示出來的風險等級並沒有預計的那么高。
所以我們測試活動的產出和收集到的信息要用來對風險評估結果進行持續的反饋和調整更新，並根據調整后的風險等級繼續指導測試。風險分析應該是一個貫穿項目研發過程始末的工作。