軟件項目風險是指在軟件開發過程中遇到的預算和進度等方面的問題以及這些問題對軟件項目的影響。軟件項目風險會影響項目計劃的實現,如果項目風險變成現實,就有可能影響項目的進度,增加項目的成本,甚至使軟件項目不能實現。如果對項目進行風險管理,就可以最大限度的減少風險的發生。但是,目前國內的軟件企業不太關心軟件項目的風險管理,結果造成軟件項目經常性的延期、超過預算,甚至失敗。成功的項目管理一般都對項目風險進行了良好的管理。因此任何一個系統開發項目都應將風險管理作為軟件項目管理的重要內容。
在項目風險管理中,存在多種風險管理方法與工具,軟件項目管理只有找出最適合自己的方法與工具并應用到風險管理中,才能盡量減少軟件項目風險,促進項目的成功。
項目風險管理
項目風險管理是指為了最好的達到項目的目標,識別、分配、應對項目生命周期內風險的科學與藝術。項目風險管理的目標是使潛在機會或回報最大化,使潛在風險最小化。風險管理涉及的主要過程包括:風險識別,風險量化,風險應對計劃制定和風險監控,如圖1所示。風險識別在項目的開始時就要進行,并在項目執行中不斷進行。就是說,在項目的整個生命周期內,風險識別是一個連續的過程。
(1)風險識別:風險識別包括確定風險的來源,風險產生的條件,描述其風險特征和確定哪些風險事件有可能影響本項目。風險識別不是一次就可以完成的事,應當在項目的自始至終定期進行。
(2)風險量化:涉及對風險及風險的相互作用的評估,是衡量風險概率和風險對項目目標影響程度的過程。風險量化的基本內容是確定那些事件需要制定應對措施。。
(3)風險應對計劃制定:針對風險量化的結果,為降低項目風險的負面效應制定風險應對策略和技術手段的過程。風險應對計劃依據風險管理計劃、風險排序、風險認知等依據,得出風險應對計劃、剩余風險、次要風險以及為其它過程提供得依據。
(4)風險監控:涉及整個項目管理過程中的風險進行應對。該過程的輸出包括應對風險的糾正措施以及風險管理計劃的更新。
每個步驟所使用的工具和方法詳見表1:
表1 風險管理過程中所使用的工具、方法
風險管理步驟 所使用的工具、方法 風險識別 頭腦風暴法、面談、Delphi法、核對表、SWOT技術 風險量化 風險因子計算、PERT估計、決策樹分析、風險模擬 風險應對計劃制定 回避、轉移、緩和、接受 風險監控 核對表、定期項目評估、掙值分析
軟件項目中的風險管理
1、軟件項目中的風險
軟件項目的風險無非體現在以下四個方面:需求、技術、成本和進度。IT項目開發中常見的風險有如下幾類:
(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從技術和商業兩個角度對軟件風險管理進行剖析,考慮的問題涉及開銷、進度、技術性能等。它還提供了一些指標和模型來估量和預測風險,由于這些數據來源于大量的實際經驗,因此具有很強的說服力。
結束語
軟件項目管理從某種意義上講,就是風險管理。我們盡量去定義明確不變的需求,以便進行計劃并高效管理,但商業環境總是快速變化的,甚至是無序的變化。所以,軟件企業在進行項目管理的過程中,必須采用適合自己的風險管理方法進行風險管理,以確保軟件項目在規定的預算和期限內完成項目。