軟件項目風險管理

根據風險內容，我們可以將風險分為：
　　(1)產品規模風險：與軟件的總體規模相關的風險。
　　(2)商業影響風險：商業風險影響到軟件開發的生存能力。商業風險包含的五個主要的風險是：
　　l 市場風險：開發了一個沒有人真正需要的優秀產品或系統；
　　l 策略風險：開發的產品不符合公司的整體商業策略；
　　l 銷售風險：開發了一個銷售部門不知道如何去賣的產品；
　　l 管理風險：由于重點的轉移或人員的變動而失去了高級管理層的支持的風險；
　　l 預算風險：沒有得到預算或人力上的保證。
　　(3)客戶特性風險：與客戶的素質以及開發者和客戶溝通能力相關的風險。
　　(4)過程定義風險：與軟件過程定義相關的風險。
　　(5)開發環境風險：與開發工具的可用性及質量相關的風險。
　　(6)技術風險：技術風險是指在設計、實現、接口、驗證、維護、規約的二義性、技術的不確定性、陳舊的技術等方面存在的風險。技術風險威脅到軟件開發的質量及交付的時間，如果技術風險變成現實，則開發工作可能變得很困難或根本不可能。
　　(7)人員數目及經驗帶來的風險：與參與工作的軟件工程師的總體技術水平及項目經驗相關的風險。
　　在進行具體的軟件項目風險識別時，可以根據實際情況對風險分類。但簡單的分類并不是總行的通的，某些風險根本無法預測。在這里，我們介紹一下美國空軍軟件項目風險管理手冊中指出的如何識別軟件風險。這種識別方法要求項目管理者根據項目實際情況標識影響軟件風險因素的風險驅動因子，這些因素包括以下幾個方面。
　　(1)性能風險：產品能夠滿足需求和符合使用目的的不確定程度。
　　(2)成本風險：項目預算能夠被維持的不確定的程度。
　　(3)支持風險：軟件易于糾錯、適應及增強的不確定的程度。
　　(4)進度風險：項目進度能夠被維持且產品能按時交付的不確定的程度。
　　每一個風險驅動因子對風險因素的影響均可分為四個影響類別--可忽略的、輕微的、嚴重的及災難性的。
　　五、風險分析
　　在進行了風險辨識后，我們就要進行風險估算，風險估算從以下幾個方面評估風險清單中的每一個風險：
　　(1)建立一個尺度，以反映風險發生的可能性；
　　(2)描述風險的后果；
　　(3)估算風險對項目及產品的影響；
　　(4)標注風險預測的整體精確度，以免產生誤解。
　　對辨識出的風險進行進一步的確認后分析風險，即假設某一風險出現后，分析是否有其他風險出現，或是假設這一風險不出現，分析它將會產生什么情況，然后確定主要風險出現最壞情況后，如何將此風險的影響降低到最小，同時確定主要風險出現的個數及時間。進行風險分析時，最重要的是量化不確定性的程度和每個風險可能造成損失的程度。為了實現這點，必須考慮風險的不同類型。識別風險的一個方法是建立風險清單，清單上列舉出在任何時候可能碰到的風險最重要的是要對清單的內容隨時進行維護，更新風險清單，并向所有的成員公開，應鼓勵項目團隊的每個成員勇于發現問題并提出警告。建立風險清單的一個辦法是將風險輸入缺陷追蹤系統中，建立風險追蹤工具，缺失追蹤系統一般能將風險項目標示為已解決或尚待處理狀態，也能指定解決問題的項目團隊成員，并安排處理順序。風險清單給項目管理提供了一種簡單的風險預測技術，下表事一個風險清單的例子：
　　風險 類別 概率 影響
　　資金將會流失 商業風險 40% 1
　　技術達不到預期效果 技術風險 30% 1
　　人員流動頻繁 人員風險 60% 3
　　在風險清單中，風險的概率值可以由項目組成員個別估算，然后加權平均，得到一個有代表性的值。也可以通過先做個別估算而后求出一個有代表性的值來完成。對風險產生的影響可以對影響評估的因素進行分析。
　　一旦完成了風險清單的內容，就要根據概率進行排序，高發生率、高影響的風險放在上方，依次類推。項目管理者對排序進行研究，并劃分重要和次重要的風險，對次重要的風險再進行一次評估并排序。對重要的風險要進行管理。從管理的角度來考慮，風險的影響及概率是起著不同作用的，一個具有高影響且發生概率很低的風險因素不應該花太多的管理時間，而高影響且發生率從中到高的風險以及低影響且高概率的風險，應該首先列入管理考慮之中。
　　在這里，我們需要強調的是如何評估風險的影響，如果風險真的發生了，它所產生的后果會對三個因素產生影響：風險的性質、范圍及時間。風險的性質是指當風險發生時可能產生的問題。風險的范圍是指風險的嚴重性及其整體分布情況。風險的時間是指主要考慮何時能夠感到風險及持續多長時間。可以利用風險清單進行分析，并在項目進展過程中迭代使用。項目組應該定期復查風險清單，評估每一個風險，以確定新的情況是否引起風險的概率及影響發生改變。這個活動可能會添加新的風險，刪除一些不再有影響的風險，并改變風險的相對位置。
　　在風險評估過程中，我們可以采取以下的步驟：
　　(1)定義項目的風險參考水平值。要使風險評估發生作用，就要定義一個風險參考水平值，對于大多數項目而言，通過對性能、成本、支持及進度等因素的分析，可以找出風險的參考水平值，對于性能下降、成本超支、支持困難或進度延遲（或者這四種的組合）等情況，超過這一參考水平值項目就會被終止。
　　(2)建立每一組（風險、風險發生的概率、風險產生的影響）與每一個參考水平值的關系。
　　(3)預測一組臨界點以定義項目終止區域，該區域由一條曲線或不確定區域界定。
　　(4)預測什么樣的風險組合會影響參考水平值。
　　六、風險駕馭
　　風險駕馭包括對策指定、風險緩解、風險監控、風險跟蹤等內容。
　　所有風險分析活動都只有一個目的--輔助項目組建立處理風險的策略。如果軟件項目組對于風險采取主動的方法，則避免永遠是最好的策略。這可以通過建立一個風險緩解計劃來達到即制定對策。
　　對不同的風險項要建立不同的風險駕馭和監控的策略比。如對于開發人員離職的風險項目開始時應作好人員流動的準備采取一些措施確保人員一旦離開時項目仍能繼續；制定文檔標準并建立一種機制保證文檔及時產生；對每個關鍵性技術崗位要培養后備人員。對于技術風險，可以采用的策略有，對采用的關鍵技術進行分析，避免軟件在生命周期中很快落后；在項目開發過程中保持對風險因素相關信息的收集工作，減少對合作公司的依賴尤其是對延續性強的項目應該盡可能地吸收合作公司的技術并變為自己的技術，避免因為可能發生的與合作公司合作的終止帶來的影響和風險降低投入成本。
　　一個有效的策略必須考慮風險避免、風險監控和風險管理及意外事件計劃這樣三個問題。風險的策略管理可以包含在軟件項目計劃中，或者風險管理步驟也可以組成一個獨立的風險緩解、監控和管理計劃（RMMM計劃）。RMMM計劃將所有風險分析工作文檔化，并且由項目管理者作為整個項目計劃的一部分來使用，RMMM計劃的大綱主要包括：主要風險，風險管理者，項目風險清單，風險緩解的一般策略、特定步驟，監控的因素和方法，意外事件和特殊考慮的風險管理等。一旦建立了RMMM計劃，我們就開始了風險緩解及監控，風險緩解是一種避免問題的活動，風險監控則是跟蹤項目的活動。它有三個主要目的：評估一個被預測的風險是否真的發生了；保證為風險而定義的緩解步驟被正確地實施；收集能夠用于未來的風險分析信息。
　　軟件開發是高風險的活動。如果項目采取積極風險管理的方式，就可以避免或降低許多風險，而這些風險如果沒有處理好，就可能使項目陷入癱瘓中。因此在軟件項目管理中還要進行風險跟蹤。對辨識后的風險在系統開發過程中進行跟蹤管理，確定還會有哪些變化，以便及時修正計劃。具體內容包括：
　　(1)實施對重要風險的跟蹤；
　　(2)每月對風險進行一次跟蹤；
　　(3)風險跟蹤應與項目管理中的整體跟蹤管理相一致；
　　(4)風險項目應隨著時間的不同而相應地變化。
　　通過風險跟蹤，進一步對風險進行管理，從而保證項目計劃的如期完成。
　　七、經典風險管理理論
　　6.1 Boehm模型
　　Boehm用公式RE=P(UO)*L(UO)對風險進行定義，其中RE表示風險或者風險所造成的影響，P(UO)表示令人不滿意的結果所發生的概率，L(UO)表示糟糕的結果會產生的破壞性的程度。在風險管理步驟上，Boehm基本沿襲了傳統的項目風險管理理論，指出風險管理由風險評估和風險控制兩大部分組成，風險評估又可分為識別、分析、設置優先級3個子步驟，風險控制則包括制定管理計劃、解決和監督風險3步。
　　Boehm思想的核心是10大風險因素列表，其中包括人員短缺、不合理的進度安排和預算、不斷的需求變動等。針對每個風險因素，Boehm都給出了一系列的風險管理策略。在實際操作時，以10大風險列表為依據，總結當前項目具體的風險因素，評估后進行計劃和實施，在下一次定期召開的會議上再對這10大風險因素的解決情況進行總結，產生新的10大風險因素表，依此類推。
　　10大風險列表的思想可以將管理層的注意力有效地集中在高風險、高權重、嚴重影響項目成功的關鍵因素上，而不需要考慮眾多的低優先級的細節問題。而且，這個列表是通過對美國幾個大型航空或國防系統軟件項目的深入調查，編輯整理而成的，因此有一定的普遍性和實際性。但是它只是基于對風險因素集合的歸納，尚未有文章論述其具體的理論基礎、原始數據及其歸納方法。另外，Boehm也沒有清晰明確地說明風險管理模型到底要捕獲哪些軟件風險的特殊方面，因為列舉的風險因素會隨著多個風險管理方法而變動，同時也互相影響。這就意味著風險列表需要改進和擴充，管理步驟也需要優化。
　　雖然其理論存在一些不足，但Boehm畢竟可以說是軟件項目風險管理的開山鼻祖。在其之后，更多的組織和個人開始了對風險管理的研究，軟件項目風險管理的重要性日益得到認同。
　　6.2 CRM模型
　　SEI（Software Engineering Institution）作為世界上著名的旨在改善軟件工程管理實踐的組織，也對風險管理投入了大量的熱情。SEI提出了持續風險管理管理模型CRM（Continuous Risk Management）。
　　SEI的風險管理原則是：不斷地評估可能造成惡劣后果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測并確保風險策略實施的有效性。
　　CRM模型要求在項目生命期的所有階段都關注風險識別和管理，它將風險管理劃分為5個步驟：風險識別、分析、計劃、跟蹤、控制。框架顯示了應用CRM的基礎活動及其之間的交互關系，強調了這是一個在項目開發過程中反復持續進行的活動序列。每個風險因素一般都需要按順序經過這些活動，但是對不同風險因素開展的不同活動可以是并發的或者交替的。
　　6.3 Leavitt模型
　　SEI和Boehm的模型都以風險管理的過程為主體，研究每個步驟所需的參考信息及其操作。而Aalborg大學提出的思路則是以Leavitt模型為基礎，著重從導致軟件開發風險的不同角度出發探討風險管理。
　　1964年提出的Leavitt模型將形成各種系統的組織劃分為4個有趣的組成部分：任務、結構、角色和技術。這4個組成部分和軟件開發的各因素很好地對應起來：角色覆蓋了所有的項目參與者，例如軟件用戶、項目經理和設計人員等；結構表示項目組織和其他制度上的安排；技術則包括開發工具、方法、硬件軟件平臺；任務描述了項目的目標和預期結果。Leavitt模型的關鍵思路是：模型的各個組成部分是密切相關的，一個組成部分的變化會影響其他的組成部分，如果一個組成部分的狀態和其他的狀態不一致，就會造成比較嚴重的后果，并可能降低整個系統的性能。