軟體專案管理中的風險管理研究

摘要：介紹了專案風險管理的過程及常用的工具和方法，討論了軟體專案中經常面臨的風險型別和經典的風險管理模型。

引言

軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理，就可以最大限度的減少風險的發生。但是，目前國內的軟體企業不太關心軟體專案的風險管理，結果造成軟體專案經常性的延期、超過預算，甚至失敗。成功的專案管理一般都對專案風險進行了良好的管理。因此任何乙個系統開發專案都應將風險管理作為軟體專案管理的重要內容。

在專案風險管理中，存在多種風險管理方法與工具，軟體專案管理只有找出最適合自己的方法與工具並應用到風險管理中，才能儘量減少軟體專案風險，促進專案的成功。

專案風險管理

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

圖1 專案風險管理過程

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

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

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

每個步驟所使用的工具和方法詳見表1：

表1 風險管理過程中所使用的工具、方法

風險管理步驟

所使用的工具、方法

風險識別

頭腦風暴法、面談、delphi法、核對表、swot技術

風險量化

風險因子計算、pert估計、決策樹分析、風險模擬

風險應對計畫制定

迴避、轉移、緩和、接受

風險監控

核對表、定期專案評估、掙值分析

軟體專案中的風險管理

1、軟體專案中的風險

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

（1）需求風險

①需求已經成為專案基準，但需求還在繼續變化；

②需求定義欠佳，而進一步的定義會擴充套件專案範疇；

③新增額外的需求；

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

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

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

（2）計畫編制風險

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

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

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

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

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

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

（3）組織和管理風險

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

②低效的專案組結構降低生產率；

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

④預算削減，打亂專案計畫；

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

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

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

（4）人員風險

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

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

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

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

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

⑥由於專案組成員之間發生衝突，導致溝通不暢、設計欠佳、介面出現錯誤和額外的重複工作；

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

⑧沒有找到專案急需的具有特定技能的人。

（5）開發環境風險

①設施未及時到位；

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

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

④開發工具未及時到位；

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

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

（6）客戶風險

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

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

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

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

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

⑥客戶提供的元件質量欠佳，導致額外的測試、設計和整合工作，以及額外的客戶關係管理工作。

（7）產品風險

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

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

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

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

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

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

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

（8）設計和實現風險

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

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

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

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

⑤分別開發的模組無法有效整合，需要重新設計或製作。

（9）過程風險

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

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

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

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

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

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

2、軟體專案風險管理模型

針對軟體專案中的風險管理問題，不少專家、組織提出了自己的風險管理模型。主要的風險管理模型有：boehm模型，crm模型和serim模型。

2.1 barry boehm模型

模型：re=p (uo)*l (uo)

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

2.2 sei的crm(continuous risk management)模型

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

2.3 serim(software engineering risk model)模型

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

結束語

軟體專案管理從某種意義上講，就是風險管理。我們盡量去定義明確不變的需求，以便進行計畫並高效管理，但商業環境總是快速變化的，甚至是無序的變化。所以，軟體企業在進行專案管理的過程中，必須採用適合自己的風險管理方法進行風險管理，以確保軟體專案在規定的預算和期限內完成專案。

軟體專案管理中的風險管理研究

軟體專案管理中的風險管理研究

軟體專案中的風險管理

專案管理 風險管理

相關推薦

專案管理風險管理