軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理，就可以最大限度的減少風險的發生。但是，目前國內的軟體企業不太關心軟體專案的風險管理，結果造成軟體專案經常性的延期、超過預算，甚至失敗。成功的專案管理一般都對專案風險進行了良好的管理。因此任何乙個系統開發專案都應將風險管理作為軟體專案管理的重要內容。 在專案風險管理中，存在多種風險管理方法與工具，軟體專案管理只有找出最適合自己的方法與工具並應用到風險管理中，才能儘量減少軟體專案風險，促進專案的成功。 專案風險管理 專案風險管理是指為了最好的達到專案的
目標，識別、分配、應對專案生命週期內風險的科學與藝術。專案風險管理的目標是使潛在機會或回報最大化，使潛在風險最小化。風險管理涉及的主要過程包括：風險識別，風險量化，風險應對計畫制定和風險監控，如圖1所示。風險識別在專案的開始時就要進行，並在專案執行中不斷進行。就是說，在專案的整個生命週期內，風險識別是乙個連續的過程。 （1）風險識別：風險識別包括確定風險的**，風險產生的條件，描述其風險特徵和確定哪些風險事件有可能影響本專案。風險識別不是一次就可以完成的事，應當在專案的自始至終定期進行。 （2）風險量化：涉及對風險及風險的相互作用的評估，是衡量風險概率和風險對專案目標影響程度的過程。風險量化的基本內容是確定那些事件需要制定應對措施。。 （3）風險應對計畫制定：針對風險量化的結果，為
降低專案風險的負面效應制定風險應對策略和技術手段的過程。風險應對計畫依據風險管理計畫、風險排序、風險認知等依據，得出風險應對計畫、剩餘風險、次要風險以及為其它過程提供得依據。 （4）風險監控：涉及整個專案管理過程中的風險進行應對。該過程的輸出包括應對風險的糾正措施以及風險管理計畫的更新。 風險管理步驟 所使用的工具、方法 http://blog.mypm.net 風險識別 頭腦風暴法、面談、delp[自定義表情]法、核對表、swot技術 風險量化 風險因子計算、pert估計、決策樹分析、風險模擬 風險應對計畫制定 迴避、轉移、緩和、接受 http://bbs.mypm.net 風險監控 核對表、定期專案評估、掙值分析 軟體專案中的風險管理 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)模型 s
ei crm模型的風險管理原則是：不斷地評估可能造成惡劣後果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測並確保風險策略實施的有效性。crm模型要求在專案生命期的所有階段都關注風險識別和管理，它將風險管理劃分為五個步驟：風險識別、分析、計畫、跟蹤、控制。 2.3 serim(software engineering risk model)模型 serim從技術和商業兩個角度對軟體風險管理進行剖析，考慮的問題涉及開銷、進度、技術效能等。它還提供了一些指標和模型來估量和**風險，由於這些資料**於大量的實際經驗，因此具有很強的說服力。 結束語 軟體專案管理從某種意義上講，就是風險管理。我們盡量去定義明確不變的需求，以便進行計畫並高效管理，但商業環境總是快速變化的，甚至是無序的變化。所以，軟體企業在進行專案管理的過程中，必須採
用適合自己的風險管理方法進行風險管理，以確保軟體專案在規定的預算和期限內完成專案。
軟體專案風險分析
與任何其他工程專案一樣，軟體工程專案的開發也存在各種各樣的風險，有些風險甚至是災難性的。r.charette認為，風險與將要發生的事情有關，它涉及諸如思想 觀念 行為 地點 時間等多種因素 風險隨條件的變化而改變，人們改變 選擇 控制與風險密切相關的條件可以減少風險，但改變 選擇 控制條件的策略往往...
軟體專案 風險管理用到的實踐 軟體專案風險管理
軟體專案風險管理是軟體專案管理的重要內容。在進行軟體專案風險管理時，要辯識風 險，評估它們出現的概率及產生的影響，然後建立乙個規劃來管理風險。風險 管理的主要 目標是預防風險。軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以 及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現...
專案風險管理
風險管理活動就是設法最小化由不可 因素導致的專案失敗的可能性。對專案的成功產生不利影響的條件和事件，都可以認為是專案風險。風險的發生是有概率性的 一旦發生，對專案的影響是不利的或有害的 風險是可能發生的，潛在的，對專案實施有影響的事情 問題issue 是當前時間窗之內已經發生或者已經確定一定會發生的...