簡介
軟體項目風險管理是軟體項目管理的重要內容。在進行軟體項目風險管理時，要辯識風險，評估它們出現的機率及產生的影響，然後建立一個規劃來管理風險。風險管理的主要目標是預防風險。
軟體項目風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體項目的影響。軟體項目風險會影響項目計畫的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟體項目不能實現。如果對項目進行風險管理，就可以最大限度的減少風險的發生。但是，目前國內的軟體企業不太關心軟體項目的風險管理，結果造成軟體項目經常性的延期、超過預算，甚至失敗。成功的項目管理一般都對項目風險進行了良好的管理。因此任何一個系統開發項目都應將風險管理作為軟體項目管理的重要內容。
在項目風險管理中，存在多種風險管理方法與工具，軟體項目管理只有找出最適合自己的方法與工具並套用到風險管理中，才能儘量減少軟體項目風險，促進項目的成功。
軟體項目的風險管理是軟體項目管理的重要內容。在進行軟體項目風險管理時，要辯識風險，評估它們出現的機率及產生的影響，然後建立一個規劃來管理風險。風險管理的主要目標是預防風險。本文探討了風險管理的主要內容和方法，介紹了風險管理的經典理論，比較了幾種主流的風險管理策略和模型。
近幾年來軟體開發技術、工具都有了很大的進步，但是軟體項目開發逾時、超支、甚至不能滿足用戶需求而根本沒有得到實際使用的情況仍然比比皆是。軟體項目開發和管理中一直存在著種種不確定性，嚴重影響著項目的順利完成和提交。但這些軟體風險並未得到充分的重視和系統的研究。直到20世紀80年代，Boehm比較詳細地對軟體開發中的風險進行了論述，並提出軟體風險管理的方法。Boehm認為，軟體風險管理指的是“試圖以一種可行的原則和實踐，規範化地控制影響項目成功的風險”，其目的是“辨識、描述和消除風險因素，以免它們威脅軟體的成功運作”。
在此基礎上，業界對軟體風險管理的研究開始慢慢豐富起來，理論上對風險進行了一些分類，提出了風險管理的思路；實踐上也出現了一些定量管理風險的方法和風險管理的軟體工具。雖然業界對風險管理表現了極大的興趣，做出了不少努力，但似乎很少開發項目的組織真正積極地在軟體開發過程中使用風險管理的方法。1995年IWSED（International Workshop on Software Engineering Data）會議做出的調查顯示：風險管理技術沒有得到廣泛套用的原因並不是大家不相信這種技術的實效性，而是對風險管理的技術和實踐缺乏了解。因此，我們認為很有必要對風險管理進行研究。
軟體項目風險管理
軟體開發中的風險是指軟體開發過程中及軟體產品本身可能造成的傷害或損失。風險關注未來的事情，這意味著，風險涉及選擇及選擇本身包含的不確定性，軟體開發過程及軟體產品都要面臨各種決策的選擇。風險是介於確定性和不確定性之間的狀態，是處於無知和完整知識之間的狀態。另一方面，風險將涉及思想、觀念、行為、地點等因素的改變。
當在軟體工程領域考慮風險時，我們要關注以下的問題：什麼樣的風險會導致軟體項目的徹底失敗；用戶需求、開發技術、目標計算機以及所有其他與項目有關的因素的改變將會對按時交付和總體成功產生什麼影響；對於採用何種方法和工具，需要多少人員參與工作的問題，我們如何選擇和決策；軟體質量要達到什麼程度才是“足夠的”。當沒有辦法消除風險，甚至連試圖降低該風險也存在疑問時，這些風險就是真正的風險了。在我們能夠標識出軟體項目中的真正風險之前，識別出所有對管理者和開發者而言均為明顯的風險是很重要的。
風險管理在項目管理中占有非常重要的地位。首先，有效的風險管理可以提高項目的成功率。其次，風險管理可以增加團隊的健壯性。與團隊成員一起進行風險分析可以讓大家對困難有充分估計，對各種意外有心理準備，大大提高組員的信心，從而穩定隊伍。第三，有效的風險管理可以幫助項目經理抓住工作重點，將主要精力集中於重大風險，將工作方式從被動救火轉變為主動防範。
被動風險策略是針對可能發生的風險來監督項目，直到它們變成真正的問題時，才會撥出資源來處理它們。更普遍的是，軟體項目組對風險不聞不問，直到發生了錯誤才趕緊採取行動，試圖迅速地糾正錯誤。這種管理模式常常被稱為“救火模式”。當補救的努力失敗後，項目就處在真正的危機之中了。
對於風險管理的一個更聰明的策略是主動式的。主動策略早在技術工作開始之前就已經啟動了。標識出潛在的風險，評估它們出現的機率及產生的影響，對風險按重要性進行排序，然後，軟體項目組建立一個計畫來管理風險。主動策略中的風險管理，其主要目標是預防風險。但是，因為不是所有的風險都能夠預防，所以，項目組必須建立一個應付意外事件的計畫，使其在必要時能夠以可控的及有效的方式做出反應m任何一個系統開發項目都應將風險管理作為軟體項目管理的重要內容。
在進行軟體項目風險管理時，要標識出潛在的風險，評估它們出現的機率及產生的影響，並按重要性加以排序，然後建立一個規劃來管理風險。風險管理的主要目標是預防風險，但不是所有的風險都能夠預防。所以必須建立一個意外事件計畫，使其在必要時能以可控的和有效的方式做出反應。風險管理目標的實現包含三個要素。首先，必須在項目計畫書中寫下如何進行風險管理；第二，項目預算必須包含解決風險所需的經費，如果沒有經費，就無法達到風險管理的目標；第三，評估風險時，風險的影響也必須納入項目規劃中。
風險管理涉及的主要過程包括：風險識別，風險量化，風險應對計畫制定和風險監控，如圖1所示【1】【3】。風險識別在項目的開始時就要進行，並在項目執行中不斷進行。就是說，在項目的整個生命周期內，風險識別是一個連續的過程。
風險識別：風險識別包括確定風險的來源，風險產生的條件，描述其風險特徵和確定哪些風險事件有可能影響本項目。風險識別不是一次就可以完成的事，應當在項目的自始至終定期進行。
風險量化：涉及對風險及風險的相互作用的評估，是衡量風險機率和風險對項目目標影響程度的過程。風險量化的基本內容是確定那些事件需要制定應對措施。。
風險應對計畫制定：針對風險量化的結果，為降低項目風險的負面效應制定風險應對策略和技術手段的過程。風險應對計畫依據風險管理計畫、風險排序、風險認知等依據，得出風險應對計畫、剩餘風險、次要風險以及為其它過程提供得依據。
風險監控：涉及整個項目管理過程中的風險進行應對。該過程的輸出包括應對風險的糾正措施以及風險管理計畫的更新。
每個步驟所使用的工具和方法詳見表1：
軟體項目中的風險
軟體項目的風險無非體現在以下四個方面：需求、技術、成本和進度。IＴ項目開發中常見的風險有如下幾類：
ü 需求風險
①需求已經成為項目基準,但需求還在繼續變化;②需求定義欠佳,而進一步的定義會擴展項目範疇;③添加額外的需求;④產品定義含混的部分比預期需要更多的時間;⑤在做需求中客戶參與不夠;⑥缺少有效的需求變化管理過程。
ü 計畫編制風險
①計畫、資源和產品定義全憑客戶或上層領導口頭指令,並且不完全一致;②計畫是最佳化的,是"最佳狀態",但計畫不現實,只能算是"期望狀態";③計畫基於使用特定的小組成員,而那個特定的小組成員其實指望不上;④產品規模(代碼行數、功能點、與前一產品規模的百分比)比估計的要大;⑤完成目標日期提前,但沒有相應地調整產品範圍或可用資源;⑥涉足不熟悉的產品領域,花費在設計和實現上的時間比預期的要多。
ü 組織和管理風險
①僅由管理層或市場人員進行技術決策,導致計畫進度緩慢,計畫時間延長;②低效的項目組結構降低生產率;③管理層審查 決策的周期比預期的時間長;④預算削減,打亂項目計畫;⑤管理層作出了打擊項目組織積極性的決定;⑥缺乏必要的規範,導至工作失誤與重複工作;⑦非技術的第三方的工作(預算批准、設備採購批准、法律方面的審查、安全保證等)時間比預期的延長。
ü 人員風險
①作為先決條件的任務(如培訓及其他項目)不能按時完成;②開發人員和管理層之間關係不佳,導致決策緩慢,影響全局;③缺乏激勵措施,士氣低下,降低了生產能力;④某些人員需要更多的時間適應還不熟悉的軟體工具和環境;⑤項目後期加入新的開發人員,需進行培訓並逐漸與現有成員溝通,從而使現有成員的工作效率降低;⑥由於項目組成員之間發生衝突,導致溝通不暢、設計欠佳、接口出現錯誤和額外的重複工作;⑦不適應工作的成員沒有調離項目組,影響了項目組其他成員的積極性;⑧沒有找到項目急需的具有特定技能的人。
ü 開發環境風險
①設施未及時到位;②設施雖到位,但不配套,如沒有電話、網線、辦公用品等;③設施擁擠、雜亂或者破損;④開發工具未及時到位;⑤開發工具不如期望的那樣有效,開發人員需要時間創建工作環境或者切換新的工具;⑥新的開發工具的學習期比預期的長,內容繁多。
ü 客戶風險
①客戶對於最後交付的產品不滿意,要求重新設計和重做;②客戶的意見未被採納,造成產品最終無法滿足用?的審核 決策周期比預期的要長;④客戶沒有或不能參與規劃、原型和規格階段的審核,導致需求不穩定和產品生產周期的變更;⑤客戶答覆的時間(如回答或澄清與需求相關問題的時間)比預期長;⑥客戶提供的組件質量欠佳,導致額外的測試、設計和集成工作,以及額外的客戶關係管理工作。
ü 產品風險
①矯正質量低下的不可接受的產品,需要比預期更多的測試、設計和實現工作;②開發額外的不需要的功能(鍍金),延長了計畫進度;③嚴格要求與現有系統兼容,需要進行比預期更多的測試、設計和實現工作;④要求與其他系統或不受本項目組控制的系統相連,導致無法預料的設計、實現和測試工作;⑤在不熟悉或未經檢驗的軟體和硬體環境中運行所產生的未預料到的問題;⑥開發一種全新的模組將比預期花費更長的時間;⑦依賴正在開發中的技術將延長計畫進度。
ü 設計和實現風險
①設計質量低下,導致重複設計;②一些必要的功能無法使用現有的代碼和庫實現,開發人員必須使用新的庫或者自行開發新的功能;③代碼和庫質量低下,導致需要進行額外的測試,修正錯誤,或重新製作;④過高估計了增強型工具對計畫進度的節省量;⑤分別開發的模組無法有效集成,需要重新設計或製作。
ü 過程風險
①大量的紙面工作導致進程比預期的慢;②前期的質量保證行為不真實,導致後期的重複工作;③太不正規(缺乏對軟體開發策略和標準的遵循),導致溝通不足,質量欠佳,甚至需重新開發;④過於正規(教條地堅持軟體開發策略和標準),導致過多耗時於無用的工作;⑤向管理層撰寫進程報告占用開發人員的時間比預期的多;⑥風險管理粗心,導致未能發現重大的項目風險。
風險辨識
識別風險是系統化地識別已知的和可預測的風險，在可能時避免這些風險，且當必要時控制這些風險。根據風險內容，我們可以將風險分為：
(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)風險項目應隨著時間的不同而相應地變化。
通過風險跟蹤，進一步對風險進行管理，從而保證項目計畫的如期完成。
經典風險管理理論
Boehm模型
Boehm用公式RE=P(UO)*L(UO)對風險進行定義，其中RE表示風險或者風險所造成的影響，P(UO)表示令人不滿意的結果所發生的機率，L(UO)表示糟糕的結果會產生的破壞性的程度。在風險管理步驟上，Boehm基本沿襲了傳統的項目風險管理理論，指出風險管理由風險評估和風險控制兩大部分組成，風險評估又可分為識別、分析、設定優先權3個子步驟，風險控制則包括制定管理計畫、解決和監督風險3步。
Boehm思想的核心是10大風險因素列表，其中包括人員短缺、不合理的進度安排和預算、不斷的需求變動等。針對每個風險因素，Boehm都給出了一系列的風險管理策略。在實際操作時，以10大風險列表為依據，總結當前項目具體的風險因素，評估後進行計畫和實施，在下一次定期召開的會議上再對這10大風險因素的解決情況進行總結，產生新的10大風險因素表，依此類推。
10大風險列表的思想可以將管理層的注意力有效地集中在高風險、高權重、嚴重影響項目成功的關鍵因素上，而不需要考慮眾多的低優先權的細節問題。而且，這個列表是通過對美國幾個大型航空或國防系統軟體項目的深入調查，編輯整理而成的，因此有一定的普遍性和實際性。但是它只是基於對風險因素集合的歸納，尚未有文章論述其具體的理論基礎、原始數據及其歸納方法。另外，Boehm也沒有清晰明確地說明風險管理模型到底要捕獲哪些軟體風險的特殊方面，因為列舉的風險因素會隨著多個風險管理方法而變動，同時也互相影響。這就意味著風險列表需要改進和擴充，管理步驟也需要最佳化。
雖然其理論存在一些不足，但Boehm畢竟可以說是軟體項目風險管理的開山鼻祖。在其之後，更多的組織和個人開始了對風險管理的研究，軟體項目風險管理的重要性日益得到認同。
CRM模型
SEI（Software Engineering Institution）作為世界上著名的旨在改善軟體工程管理實踐的組織，也對風險管理投入了大量的熱情。SEI提出了持續風險管理管理模型CRM（Continuous Risk Management）。
SEI的風險管理原則是：不斷地評估可能造成惡劣後果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測並確保風險策略實施的有效性。
CRM模型要求在項目生命期的所有階段都關注風險識別和管理，它將風險管理劃分為5個步驟：風險識別、分析、計畫、跟蹤、控制。下圖所示的框架顯示了套用CRM的基礎活動及其之間的互動關係，強調了這是一個在項目開發過程中反覆持續進行的活動序列。每個風險??風險因素開展的不同活動可以是並發的或者交替的。
![軟體風險管理](<IMG title=軟體風險管理 alt=軟體風險管理 src="http://a0.att.baike.com/53/92/01000000000000119079217192453_s.jpg">)
圖中的箭頭標識了信息的邏輯流，而溝通則是信息流的核心和手段。其中，風險識別依靠問卷完成，問卷覆蓋了大概200個問題，一共涉及13個主要領域。風險分析側重於理解每個風險在該項目中的發生幾率和後果嚴重性，從而產生最嚴重的10大風險問題。風險計畫是將如下內容文檔化：風險管理步驟的描述、負責人及其職責、行為執行和完結的時間，並且確定風險處理的優先權，制定整體的管理計畫。風險跟蹤是獲取、整理並匯報10大風險問題當前的狀態，其目的是收集精確的、及時的和相關的信息，並將它們表達成容易理解的方式提交給負責人。風險控制是為了根據風險及其緩解計畫進行及時而有效的決策，具體操作包括分析風險跟蹤階段產生的風險狀態信息，明確地決定採取什麼行動，並實現它們。而處於核心地位的溝通則強調其有效性和針對性，要注意將合適的信息傳達給合適的組織層次以得到最有效的分析和管理，這些層次包括開發方和用戶方雙方的組織結構。
Leavitt模型
SEI和Boehm的模型都以風險管理的過程為主體，研究每個步驟所需的參考信息及其操作。而Aalborg大學提出的思路則是以Leavitt模型為基礎，著重從導致軟體開發風險的不同角度出發探討風險管理。
1964年提出的Leavitt模型將形成各種系統的組織劃分為4個有趣的組成部分：任務、結構、角色和技術。這4個組成部分和軟體開發的各因素很好地對應起來：角色覆蓋了所有的項目參與者，例如軟體用戶、項目經理和設計人員等；結構表示項目組織和其他制度上的安排；技術則包括開發工具、方法、硬體軟體平台；任務描述了項目的目標和預期結果。Leavitt模型的關鍵思路是：模型的各個組成部分是密切相關的，一個組成部分的變化會影響其他的組成部分，如果一個組成部分的狀態和其他的狀態不一致，就會造成比較嚴重的後果，並可能降低整個系統的性能。
將這個模型和軟體風險的概念相對應，即一個系統開發過程中任何Leavitt組成成分的修改都會產生一些問題，甚至導致軟體修改的失敗。根據Leavitt模型，任何導致風險發生的因素都可以歸結為模型中的組成部分，例如技術及其可行性；或者歸結為組成部分之間的聯繫，例如程式開發人員使用某一技術的能力。因此，使用Leavitt模型從4個方面分別識別和分析軟體項目的風險是極有條理性和比較全面的。在進行軟體項目管理時，可以採用不同的方法對不同的方面進行風險管理。
Leavitt模型實際上是提出一個框架，可以更加廣泛和系統地將軟體風險的相關信息組織起來。Leavitt理論的設計方法和實現研究已經廣泛套用於信息系統中，它所考慮的都是軟體風險管理中十分重要的環節，而且簡單、定義良好、適用於分析風險管理步驟。
總結
總之，在軟體項目開發過程中，當對軟體的期望很高時，一般都會進行項目風險分析、預測、評估、管理及監控等風險管理。通過風險管理可以使項目進程更加平穩，可以獲得很高的跟蹤和控制項目的能力，並且可以增強項目組成員對項目如期完成的信心。風險管理是項目管理中很重要的管理活動，有效的實施軟體風險管理是軟體項目開發工作順利完成的保證。
參考文獻
【1】Boehm B，Software Risk Management：Principle sand Practices，IEEE Software 1991-01
【2】http：//www.cs.umd.edu/projects/SoftEng/ESEG/iwsed/iwsed95/Data_sum.html
【3】Boehm BW，Software Engineering Economics，Englewood Cliffs，1981
【4】Chittister，Clyde，Risk Management in Practice，SEI Technical Review，1993
【5】RogerL，ScoyV，Software Development Risk，Opportunity，Not Problem，1992-09
【6】Lyytinen K，Mathiassen L，Attention Shaping and Software Risk A Categorial Analysis of Four Classical Approaches，1996
【7】陳佳，信息系統開發方法教程
【8】史蒂夫·麥克康奈爾，微軟項目求生法則
