軟件項目風險是指在軟件開發過程中遇到的預算和進度等方面的問題以及這些問題對軟件項目的影響。軟件項目風險會影響項目計劃的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟件項目不能實現。如果對項目進行風險管理，就可以最大限度的減少風險的發生。

項目風險管理

項目風險管理是指為了最好的達到項目的目標，識別、分配、應對項目生命周期內風險的科學與藝術。項目風險管理的目標是使潛在機會或回報最大化，使潛在風險最小化。風險管理涉及的主要過程包括：風險識別，風險量化，風險應對計劃制定和風險監控，如圖1所示。風險識別在項目的開始時就要進行，並在項目執行中不斷進行。就是說，在項目的整個生命周期內，風險識別是一個連續的過程。

（1）風險識別：風險識別包括確定風險的來源，風險產生的條件，描述其風險特征和確定哪些風險事件有可能影響本項目。風險識別不是一次就可以完成的事，應當在項目的自始至終定期進行。

（2）風險量化：涉及對風險及風險的相互作用的評估，是衡量風險概率和風險對項目目標影響程度的過程。風險量化的基本內容是確定那些事件需要制定應對措施。

（3）風險應對計劃制定：針對風險量化的結果，為降低項目風險的負面效應制定風險應對策略和技術手段的過程。風險應對計劃依據風險管理計劃、風險排序、風險認知等依據，得出風險應對計劃、剩余風險、次要風險以及為其它過程提供得依據。

（4）風險監控：涉及整個項目管理過程中的風險進行應對。該過程的輸出包括應對風險的糾正措施以及風險管理計劃的更新。

每個步驟所使用的工具和方法：

PMI 將風險管理分為以下 6 個過程

• 規劃風險管理：定義如何實施項目風險管理活動的過程；
• 識別風險：判斷哪些風險會影響項目並記錄其特征的過程；
• 實施定性風險分析：評估並綜合分析風險的發生概率和影響，對風險進行優先排序，從而為後續分析或行動提供基礎的過程；
• 實施風險定量分析：就已識別風險對項目整體目標的影響進行定量分析的過程；
• 規劃風險應對：針對項目目標，制定提高機會，降低威脅的方案和措施的過程；
• 監控風險：在整個項目中，實施風險應對計劃，跟蹤已識別的風險，監測殘余風險，識別新風險和評估風險過程有效性的過程；

項目風險管理的成功因素

l 對風險管理價值的認同——對組織管理、項目幹系人（內部或外部）、項目管理和項目成員來說，在項目風險管理上的投入是有潛在正面回報的。因而項目風險管理應該被認為是極富價值的。
l 個人承諾/責任——項目參與者和幹系人都應該願意承擔進行風險相關活動的責任。風險管理實際上是每個人的分內事。
l 開誠布公的溝通——每個人都應該參與到項目風險管理過程中。相對於積極處理和有效決策，任何隱藏風險的行為或態度都會降低項目風險管理的效率。
l 組織級的承諾——組織級的承諾只有在風險管理與組織的目標和價值一致時才能建立。和其他項目管理原則相比，項目風險管理需要更高級別的管理層支持，因為一些風險的應對需要比項目經理更高級的管理層批準或采取行動。
l 量化項目上風險管理的投入——項目風險管理活動應該和組織對於項目目標價值的判定，風險本身的程度、規模，以及其他組織級制約因素相一致。特別是，進行項目風險管理所需的成本應該和風險管理能給項目及組織帶來的價值相對應。
l 與項目管理整合——項目風險管理並非獨立存在於其他項目管理過程之外。成功的項目風險管理需要和其他項目管理過程的正確執行進行整合。
以上這些關鍵成功因素如下圖所示

項目風險管理中項目經理的角色

項目經理在風險管理過程中有著獨一無二的作用。項目經理對交付一個完全符合預定目標的成功項目承擔整體責任；項目經理對項目的日常管理負責，包括進行有效的風險管理。項目經理的職責包括：
l 鼓勵高層管理者支持項目風險管理活動的進行。
l 與幹系人協商確定項目風險的可接受程度。
l 編制和審批風險管理計劃。
l 在項目中推動項目風險管理過程。
l 在項目團隊、高層管理者和其他幹系人中對風險進行開誠布公的溝通。
l 參與項目風險管理過程中的方方面面。
l 在落實行動前審核風險應對和相應的行動計劃。
l 在風險發生時，批準啟用項目應急儲備來應對已識別風險。
l 監督分包商和供應商的風險管理。
l 定期向主要幹系人匯報風險的狀態，提供恰當的決策建議，以及為維持一定的風險水平應采取的措施。
l 在適當的時候將已識別的風險提升到高層管理層面，包括那些在項目經理權力或掌控範圍之外的風險、需要項目以外的其他輸入或行動的風險，以及需要動用管理儲備的風險。
l 監督項目風險管理過程執行的效率、效果。
l 審計風險應對的有效性並記錄經驗教訓。

軟件項目中的風險管理

1、軟件項目中的風險

軟件項目的風險無非體現在以下四個方面：需求、技術、成本和進度。IＴ項目開發中常見的風險有如下幾類：

（1）需求風險

1.需求已經成為項目基準，但需求還在繼續變化；

2.需求定義欠佳，而進一步的定義會擴展項目範疇；

3.產品定義含混的部分比預期需要更多的時間；

4.在做需求中客戶參與不夠；

5.缺少有效的需求變化管理過程。

（2）計劃編制風險

①計劃、資源和產品定義全憑客戶或上層領導口頭指令，並且不完全一致；

②計劃是優化的，是"最佳狀態"，但計劃不現實，只能算是"期望狀態"；

③計劃基於使用特定的小組成員，而那個特定的小組成員其實指望不上；

④產品規模(代碼行數、功能點、與前一產品規模的百分比)比估計的要大；

⑤完成目標日期提前，但沒有相應地調整產品範圍或可用資源；

⑥涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。

（3）組織和管理風險

①僅由管理層或市場人員進行技術決策，導致計劃進度緩慢，計劃時間延長；

②低效的項目組結構降低生產率；

③管理層審查 決策的周期比預期的時間長；

④預算削減，打亂項目計劃；

⑤管理層作出了打擊項目組織積極性的決定；

⑥缺乏必要的規範，導致工作失誤與重復工作；

⑦非技術的第三方的工作(預算批準、設備采購批準、法律方面的審查、安全保證等)時間比預期的延長。

（4）人員風險

①作為先決條件的任務(如培訓及其他項目)不能按時完成；

②開發人員和管理層之間關系不佳，導致決策緩慢，影響全局；

③缺乏激勵措施，士氣低下，降低了生產能力；

④某些人員需要更多的時間適應還不熟悉的軟件工具和環境；

⑤項目後期加入新的開發人員，需進行培訓並逐漸與現有成員溝通，從而使現有成員的工作效率降低；

⑥由於項目組成員之間發生沖突，導致溝通不暢、設計欠佳、接口出現錯誤和額外的重復工作；

⑦不適應工作的成員沒有調離項目組，影響了項目組其他成員的積極性；

⑧沒有找到項目急需的具有特定技能的人。

（5）開發環境風險

①設施未及時到位；

②設施雖到位，但不配套，如沒有電話、網線、辦公用品等；

③設施擁擠、雜亂或者破損；

④開發工具未及時到位；

⑤開發工具不如期望的那樣有效，開發人員需要時間創建工作環境或者切換新的工具；

⑥新的開發工具的學習期比預期的長，內容繁多。

（6）客戶風險

①客戶對於最後交付的產品不滿意，要求重新設計和重做；

②客戶的意見未被采納，造成產品最終無法滿足用戶要求，因而必須重做；

③客戶對規劃、原型和規格的審核 決策周期比預期的要長；

④客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和產品生產周期的變更；

⑤客戶答復的時間(如回答或澄清與需求相關問題的時間)比預期長；

⑥客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關系管理工作。

（7）產品風險

①矯正質量低下的不可接受的產品，需要比預期更多的測試、設計和實現工作；

②開發額外的不需要的功能(鍍金)，延長了計劃進度；

③嚴格要求與現有系統兼容，需要進行比預期更多的測試、設計和實現工作；

④要求與其他系統或不受本項目組控制的系統相連，導致無法預料的設計、實現和測試工作；

⑤在不熟悉或未經檢驗的軟件和硬件環境中運行所產生的未預料到的問題；

⑥開發一種全新的模塊將比預期花費更長的時間；

⑦依賴正在開發中的技術將延長計劃進度。

（8）設計和實現風險

①設計質量低下，導致重復設計；

②一些必要的功能無法使用現有的代碼和庫實現，開發人員必須使用新的庫或者自行開發新的功能；

③代碼和庫質量低下，導致需要進行額外的測試，修正錯誤，或重新制作；

④過高估計了增強型工具對計劃進度的節省量；

⑤分別開發的模塊無法有效集成，需要重新設計或制作。

（9）過程風險

①大量的紙面工作導致進程比預期的慢；

②前期的質量保證行為不真實，導致後期的重復工作；

③太不正規(缺乏對軟件開發策略和標準的遵循)，導致溝通不足，質量欠佳，甚至需重新開發；

④過於正規(教條地堅持軟件開發策略和標準)，導致過多耗時於無用的工作；

⑤向管理層撰寫進程報告占用開發人員的時間比預期的多；

⑥風險管理粗心，導致未能發現重大的項目風險。

軟件項目風險管理模型

針對軟件項目中的風險管理問題，不少專家、組織提出了自己的風險管理模型。主要的風險管理模型有：Boehm模型，CRM模型和SERIM模型。

1 Barry Boehm模型

模型：RE=P (UO)*L (UO)

其中RE表示風險或者風險所造成的影響，P(UO)表示令人不滿意的結果所發生的概率，L(UO)表示糟糕的結果會產生的破壞性的程度。Boehm思想的核心是10大風險因素列表。針對每個風險因素，都給出了一系列的風險管理策略。在實際操作時，Boehm以10大風險列表為依據，總結當前項目具體的風險因素，評估後進行計劃和實施，在下一次定期召開的會議上再對這10大風險因素的解決情況進行總結，產生新的10大風險因素表，依此類推。

2 SEI的CRM(Continuous Risk Management)模型

SEI

CRM模型的風險管理原則是：不斷地評估可能造成惡劣後果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測並確保風險策略實施的有效性。CRM模型要求在項目生命期的所有階段都關註風險識別和管理，它將風險管理劃分為五個步驟：風險識別、分析、計劃、跟蹤、控制。

3 SERIM(Software Engineering Risk Model)模型

SERIM從技術和商業兩個角度對軟件風險管理進行剖析，考慮的問題涉及開銷、進度、技術性能等。它還提供了一些指標和模型來估量和預測風險，由於這些數據來源於大量的實際經驗，因此具有很強的說服力。

MSF 風險管理過程

MSF 風險管理原則提倡前攝的風險管理、持續的風險評估以及項目或操作生命周期的決策集成。風險應該被持續地評估、監控和積極地管理，直到被解決或是轉化為可以處理的故障為止。圖1中描述的MSF 風險管理原則定義了項目團隊管理現有風險、計劃、執行風險管理策略以及為企業獲取知識過程中的六個邏輯階段。

MSF 風險管理過程的六個階段是：

?識別

?分析和分級

?計劃和調度

?跟蹤和報告

?控制

?學習

風險識別讓個體可以發現風險，進而使項目團隊意識到潛在的故障。作為風險管理過程的輸入，風險識別應該盡可能早的執行，並在項目的生命周期中頻繁地重復。

風險分析將風險識別過程中發現的特定項目風險估計量或數據轉化為一種可被項目團隊用來確定優先決策的形式。風險排序讓項目團隊可以負責項目資源從而對最重要的風險進行管理。

風險計劃提取風險分析中獲得的信息並用其明確表達策略、計劃和工作。風險調度可以確保計劃被認可並融入標準的日常項目管理進程和基礎設施中，從而確保風險管理作為團隊日常工作的一部分執行。風險調度明確地利用項目計劃與風險計劃關聯。

風險跟蹤監控特定風險的狀況以及它們各自工作計劃中的進展情況。風險跟蹤也包含監控變化風險的概率、影響、暴露程度以及其他因素，這些變化可能改變優先級或風險計劃、項目特性、資源或是進度表。風險跟蹤從風險等級的角度定義風險管理過程在項目中的可見度，這與標準業務項目管理過程任務完備化的角度恰恰相反。 風險報告確保團隊、發起人和投資人明白項目風險的狀態並管理它們的計劃。

風險控制是執行風險工作計劃和相關現狀報告的過程。風險控制也包含項目變化控制請求的初始化，而風險狀況或風險計劃的更改可能導致項目特性、資源或進度表的更改。

風險學習使知識和相應項目案例及工具正式化，並在團隊和企業內部以可再度使用的形式提取知識。

註意，這些階段屬於邏輯階段，對於任何給定的風險，您都並不需要嚴格地遵循這些階段。項目團隊將經常在識別-分析-計劃三步中循環往返，而僅僅周期性地進入學習這一階段來為企業捕獲知識。

CMMI過程-RSKM風險管理

SG 1 進行風險管理準備

建立並維護用於識別、分析和緩解風險的戰略。這個戰略一般編寫成項目風險管理計劃。風險管理戰略處理的是適用於控制風險管理大綱的具體措施、資源和管理方法；包括對風險來源、風險分類方案以及風險的評價、界定和控制參數等的策劃。相應的慣例：

• SP1.1 確定風險來源和類別
• SP1.2 定義風險參數
• SP1.3 建立風險管理戰略

風險的來源是多方面，對於IT項目的風險比較常見的來源是不確定的需求，人員流動，使用新技術，不合理的進度，開發人員技能不足等方面的內容。風險的類別也是多方面的，比較大的分類可以分為項目管理類的風險，業務風險，技術類風險等。註意確定風險來源和分類的目的一方面是提供一種收集和歸納風險的機制，以確保風險能夠引起管理者的關註。一方面的不同的風險類別和來源所具備的風險概率，影響，幹系人，風險閾值等基礎參數可能是不一樣的。

定義風險的參數主要是要確定風險的定義，評估和排序的準則。裏面有一個重要的內容就是確定各類風險的閾值。風險的閾值是給出風險的監督和控制點，當風險最終評估影響超過閾值的時候就必須要考慮實施風險緩解計劃。風險緩解計劃的實施可以是在我們評估的關鍵風險立刻實施，一種就是雖然現在還不是關鍵風險，但是如何風險超過了閾值就必須要實施緩解計劃。

對應SP1.3的內容可以直接理解為風險管理計劃，該計劃應該是項目計劃的重要組成部分。風險管理計劃需要定義項目風險管理小組的成員，項目采用的風險參數，風險識別的方法和工具，項目可能會采用的風險緩解策略，項目如何對風險進行監控等內容。

SG 2 識別和分析風險

識別風險並對其進行分析，以確定它們的相對重要性。風險的程度影響到為處理風險而進行的資源分配和確定何時需要相應的管理者關註。對風險進行分析也就是給內部和外部來源的風險加上標識，然後評估每個風險，確定其發生的可能性和後續結果。根據已建立的風險分類辦法和針對風險管理戰略擬訂的判據確定風險的類別，將為風險的處理提供所需的信息。可以把相關的風險分組，以便有效地處理風險和使用風險管理資源。相應的慣例:

• SP 2.1 識別風險
• SP 2.2 對風險進行評價、分類和排列先後順序

風險的識別有多種方法，頭腦風暴，調查表，風險檢查單，風險庫等都是可以考慮的內容。對於產品和技術的風險一定要借助於WBS工作分解結構來識別。在風險識別階段我們就會形成風險登記冊，要完成風險的名稱，來源，類別等基本風險屬性的錄入。

在SP2.2主要是PMBOK中談到的風險定性分析的內容。主要是要確定每個風險的影響，風險值=風險發生的概率*風險產生的影響。對我們識別的每個風險都應該得到最終風險值然後對風險進行優先級排序。在定性風險分析中引入了風險概率影響矩陣，組織和項目都可以根據概率影響矩陣來定義風險值在哪個範圍即是項目關鍵風險。當一個風險被評估我項目關鍵風險後就必須要考慮對風險進行應對和緩解。

SG 3 緩解風險

處理風險並且在適當時緩解風險，從而降低對實現項目目標的不利影響。

處理風險的步驟包括提出風險處理意見、監督風險和在規定的閾值被超出時執行風險處理活動。針對所選擇的風險擬訂並實施緩解風險的方案，主動降低風險發生時的潛在影響。這類方案可能包括用於處理所選風險萬一發生時的影響的應急方案，這與緩解風險的意圖無關。用於啟動風險處理活動的判據、閩值和參數由風險管理戰略規定。相應的慣例：

• SP 3.1 制訂風險緩解計劃
• SP 3.2 實施風險緩解計劃

風險管理戰略規定的判據、閾值和參數用於確定在什麽時候需要采取風險處理行動。風險緩解計劃只是針對項目的關鍵風險，對於一般風險僅進行監督即可。對於風險的應對常用的措施有減輕，接受，規避，轉移等，建議對於關鍵風險要有一種以上的緩解應對方法。在SP3.1中要確定風險的級別和閾值，它們指出風險在什麽情況下將變得不可接受並且將啟動風險處理行動。另外風險緩解計劃中還需要包括如何風險轉變為問題後的應急處理方法。

風險緩解計劃的實施需要定義緩解計劃的實施負責人，定期跟蹤在緩解計劃實施後風險是否得到了緩解。風險的發生概率和影響程度是否得到了降低。有了這些跟蹤和重新評估，就可以對風險狀態和優先級進行重新更新。

三級對風險管理要求是風險管理已經上升到組織級，組織有對風險管理規程，風險參數的標準定義，項目可以裁剪。另外組織會形成相應的風險庫供項目識別風險使用。四級要求對風險進行量化管理，需要量化到風險管理的子過程，如風險識別，風險分析等子過程。對風險分析應該采用一些敏感度分析，蒙特卡洛模擬等量化風險分析的方法。

項目風險管理經驗

1 風險管理要趁早。海恩法則說：任何不安全事故都是可以預防的。而防患於未然的代價顯然要好過亡羊補牢，良好的風險管理規劃是項目成功的一個保障；

2 不要忽視參考以前相關的項目經驗。項目管理本來就是一個積累的實踐過程，“前車之鑒，後車之師”，以前的項目，無論是從風險識別還是風險應對都能給現在的項目一些啟示和經驗；

3 要充分考慮項目成員對風險的態度。風險管理不是項目經理一個人的事，需要全員的參與，而不同成員對風險的態度往往也會在某種程度上決定風險應對的措施。對於風險追逐型的組員，就要考慮其對風險的分析和認識是不是偏於樂觀，同時也不能由於某些風險保守型成員對風險的態度而止步不前；

4 借助相關的風險管理工具。如 GS risk，Deltek Risk+等。其中 RPM 通過為風險和響應集中編目，並生成措施或任務來識別與記錄項目有關的問題並做出相應，從而能夠提供從計劃，監控到控制階段過程有效的風險管理，同時其強大的風險數據庫還可以為項目風險提供模板。

軟件項目風險管理介紹