軟件項目風險管理

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件項目風險管理一、風險管理概述軟件風險是指軟件開發(fā)過程中及軟件產(chǎn)品本身可能造成的傷害或損失。風險關(guān)注未來的事情，這意味著，風險涉及選擇及選擇本身包含的不確定性，在軟件開發(fā)過程及軟件產(chǎn)品都要面臨各種決策的選擇。風險是介于確定性和不確定性之間的狀態(tài)，是處于無知和完整知識之間的狀態(tài)。另一方面，風險將涉及思想、觀念、行為、地點等因素的改變。 當在軟件工程領(lǐng)域考慮風險時，我們要關(guān)注以下的問題：什么樣的風險會導(dǎo)致軟件項目的徹底失敗？用戶需求、開發(fā)技術(shù)、目標計算機、以及所有其它與項目有關(guān)的因素的改變將會對按時交付和總體成功產(chǎn)生什么影響？對于采用什么方法和工具，需要多少人員參與工作

2、的問題，我們?nèi)绾芜x擇和決策？對軟件質(zhì)量要達到什么程度才是“足夠的”？ 當沒有辦法消除風險，甚至連試圖降低該風險也存在疑問時，這些風險就是真正的風險了。在我們能夠標識出軟件項目中的真正風險之前，識別出所有對管理者和開發(fā)者而言均為明顯得風險是很重要的。二、被動和主動的風險策略被動風險策略是針對可能發(fā)生的風險來監(jiān)督項目，直到它們變成真正的問題時，才會撥出資源來處理它們，更普遍的是，軟件項目組對風險不聞不問，直到發(fā)生了錯誤才趕緊采取行動，試圖迅速地糾正錯誤。這種管理模式常常被稱為“救火模式”。當補救的努力失敗后，項目就處在真正的危機之中了。 對于風險管理的一個更聰明的策略是主動式的。主動策略早在技術(shù)工

3、作開始之前就已經(jīng)啟動了標識出潛在地風險，評估它們出現(xiàn)的概率及產(chǎn)生的影響，對風險按重要性進行排序，然后，軟件項目組建立一個計劃來管理風險。主動策略風險管理的主要目標是預(yù)防風險。但是，因為不是所有的風險都能夠預(yù)防，所以，項目組必須建立一個應(yīng)付意外事件的計劃，使其在必要時能夠以可控的及有效的方式作出反應(yīng)。三、軟件風險1、軟件風險包含兩個特征： 不確定性刻劃風險的事件可能發(fā)生也可能不發(fā)生，沒有100發(fā)生的風險。 損失如果風險變成了現(xiàn)實，就會產(chǎn)生惡性后果或損失。 2、進行風險分析時，重要的是量化不確定的程度和與每個風險相關(guān)的損失的程度。 為了實現(xiàn)這點，必須考慮以下幾種不同類型的風險： 項目風險：項目風險

4、是指潛在的預(yù)算、進度、人力（工作人員和組織）、資源、客戶、需求等方面的問題以及它們對軟件項目的影響。項目風險威脅項目計劃，如果風險變成現(xiàn)實，有可能會拖延項目的進度，增加項目的成本。項目風險的因素還包括項目的復(fù)雜性、規(guī)模、結(jié)構(gòu)的不確定性。 技術(shù)風險：是指潛在地設(shè)計、實現(xiàn)、接口、驗證和維護等方面的問題。此外規(guī)約的二義性、技術(shù)的不確定性、陳舊的技術(shù)、以及“過于先進”的技術(shù)也是風險因素。技術(shù)風險威脅要開發(fā)的軟件的質(zhì)量及交付時間。如果技術(shù)風險變成現(xiàn)實，則開發(fā)工作可能變得很困難或者不可能。 商業(yè)風險：商業(yè)風險威脅到要開發(fā)軟件的生存能力。商業(yè)風險常常會危害項目或產(chǎn)品。 五個主要的商業(yè)風險是：（1）開發(fā)一個沒

5、有人真正需要的優(yōu)秀產(chǎn)品或系統(tǒng)（市場風險）；（2）開發(fā)的產(chǎn)品不再符合公司的整體商業(yè)策略（策略風險）；（3）建造了一個銷售部門不知道如何去賣的產(chǎn)品；（4）由于重點的轉(zhuǎn)移或人員的變動而失去了高級管理層的支持（管理風險）；（5）沒有得到預(yù)算或人力上的保證（預(yù)算風險）。 3、風險分為以下方式：（1）已知風險,是通過仔細評估項目計劃、開發(fā)項目的商業(yè)及技術(shù)環(huán)境、以及其它可靠的信息來源（如：不現(xiàn)實的交付時間，沒有需求或軟件范圍的文檔、惡劣的開發(fā)環(huán)境）之后可以發(fā)現(xiàn)的那些風險。（2）可預(yù)測風險，能夠從過去項目的經(jīng)驗中推測出來（如：人員調(diào)整，與客戶之間無法溝通，由于需要進行維護而使開發(fā)人員精力分散）。（3）不可預(yù)測

6、風險，它們可能、也會真的出現(xiàn)，但很難事先識別出它們來。四、識別風險識別風險是試圖系統(tǒng)化地確定對項目計劃（估算、進度、資源分配）的威脅。通過識別已知和可預(yù)測的風險，項目管理者就有可能避免這些風險，且當必要時控制這些風險。 每一類風險可以分為兩種不同的類型：一般性風險和特定產(chǎn)品的風險。一般性風險對每一個軟件項目而言都是一個潛在地威脅。特定產(chǎn)品的風險只有那些對當前項目的技術(shù)、人員、及環(huán)境非常了解的人才能識別出來。為了識別特定產(chǎn)品的風險，必須檢查項目計劃及軟件范圍說明，從而了解本項目中有什么特殊的特性可能會威脅到項目計劃。 一般性風險和特定產(chǎn)品的風險都應(yīng)該被系統(tǒng)化地標識出來。識別風險的一個方法是建立風

7、險條目檢查表。該檢查表可以用來識別風險，并可以集中來識別下列常見子類型中已知的及可預(yù)測的風險： · 產(chǎn)品規(guī)模與要建造或要修改的軟件的總體規(guī)模相關(guān)的風險。 · 商業(yè)影響與管理或市場所加諸的約束相關(guān)的風險。 · 客戶特性與客戶的素質(zhì)以及開發(fā)者和客戶定期通信的能力相關(guān)的風險。 · 過程定義與軟件過程被定義的程度以及它們被開發(fā)組織所遵守的程度相關(guān)的風險。 · 開發(fā)環(huán)境與用以建造產(chǎn)品的工具的可用性及質(zhì)量相關(guān)的風險。 · 建造的技術(shù)與待開發(fā)軟件的復(fù)雜性以及系統(tǒng)所包含技術(shù)的“新奇性”相關(guān)的風險。 · 人員數(shù)目及經(jīng)驗與參與工作的軟件工程師的

8、總體技術(shù)水平及項目經(jīng)驗相關(guān)的風險。 風險條目檢查表能夠以不同的方式來組織。與上述話題相關(guān)的問題可以由每一個軟件項目來回答。這些問題的答案使得計劃者能夠估算風險產(chǎn)生的影響。1、產(chǎn)品規(guī)模風險 項目風險是直接與產(chǎn)品規(guī)模成正比的。下面的風險檢查表中的條目標識了產(chǎn)品（軟件）規(guī)模相關(guān)的常見風險： · 是否以LOC或FP估算產(chǎn)品的規(guī)模； · 對于估算出的產(chǎn)品規(guī)模的信任程度如何； · 是否以程序、文件或事務(wù)處理的數(shù)目來估算產(chǎn)品規(guī)模； · 產(chǎn)品規(guī)模與以前產(chǎn)品的規(guī)模的平均值的偏差百分比是多少； · 產(chǎn)品創(chuàng)建或使用的數(shù)據(jù)庫大小如何； · 產(chǎn)品的用戶數(shù)有多少

9、； · 產(chǎn)品的需求改變多少？交付之前有多少？交付之后有多少？ · 復(fù)用的軟件有多少？ 2、商業(yè)影響風險 銷售部門是受商業(yè)驅(qū)動的，而商業(yè)考慮有時會直接與技術(shù)實現(xiàn)發(fā)生沖突。下面的風險檢查表中的條目標識了與商業(yè)影響相關(guān)的常見風險： · 本產(chǎn)品對公司的收入有何影響； · 本公司是否得到公司高級管理層的重視； · 交付期限的合理性如何； · 將會使用本產(chǎn)品的用戶數(shù)及本產(chǎn)品是否與用戶的需要相符合； · 本產(chǎn)品必須能與之互操作的其它產(chǎn)品/系統(tǒng)的數(shù)目； · 最終用戶的水平如何； · 政府對本產(chǎn)品開發(fā)的約束； ·

10、 延遲交付所造成的成本消耗是多少； · 產(chǎn)品缺陷所造成的成本消耗是多少； 對于待開發(fā)產(chǎn)品的每一個回答都必須與過去的經(jīng)驗加以比較。如果出現(xiàn)了較大的百分比偏差或者如果數(shù)字接近過去很不令人滿意的結(jié)果，則風險較高。 3、客戶相關(guān)風險 客戶有不同的需要。一些人只知道他們需要什么；而另一些人知道他們不需要什么。一些客戶希望進行詳細的討論，而另客戶則滿足于模糊的承諾。 客戶有不同的個性。一些人喜歡享受客戶的身份，而另一些人則根本不喜歡做為客戶。一些人會高興地接受幾乎任何交付的產(chǎn)品，并能充分利用一個不好的產(chǎn)品；而另一些人則會對質(zhì)量差的產(chǎn)品猛烈抨擊。一些人會對質(zhì)量好的產(chǎn)品表示贊賞；而另一些人則不管怎樣

11、都抱怨不休。 客戶和供應(yīng)商之間也有各種不同的通信方式。一些人非常熟悉產(chǎn)品及生產(chǎn)廠商；而另一些人則可能素未謀面，僅僅通過信件來往和電話與生產(chǎn)廠商溝通。 一個“不好的”客戶可能會對一個軟件項目組能否在預(yù)算內(nèi)完成項目產(chǎn)生很大的影響。對于項目管理者而言，不好的客戶是對項目計劃的巨大威脅和實際的風險。下面的風險檢查表中的條目標識了與客戶特征相關(guān)的常見風險： · 你以前是否曾與這個客戶合作過； · 該客戶是否很清楚需要什么；他能否化時間把需求寫出來； · 該客戶是否同意花時間召開正式的需求收集會議，以確定項目范圍； · 該客戶是否愿意建立與開發(fā)者之間的快速通信渠道；

12、 · 該客戶是否愿意參加復(fù)審工作； · 該客戶是否具有改產(chǎn)品領(lǐng)域的技術(shù)素養(yǎng)； · 該客戶是否愿意你的人來做他們的工作； · 該客戶是否了解軟件過程； 如果對于這些問題中的任何一個答案是否定的，則需要進一步的調(diào)研，以評估潛在地風險。4、過程風險 如果軟件過程定義得不清楚；如果分析、設(shè)計、測試以無序的方式進行；如果質(zhì)量是每個人都認為很重要的概念，但沒有人切實采取行動來保證它，那么這個項目就處在風險之中。 過程問題： · 高級管理層是否有一份已經(jīng)寫好的政策陳述，該陳述中強調(diào)了軟件開發(fā)標準過程的重要性； · 開發(fā)組織是否已經(jīng)擬定了一份已經(jīng)成文

13、的、用于本項目開發(fā)的軟件過程的說明； · 開發(fā)人員是否同意按照文檔所寫的軟件過程進行開發(fā)工作，并自愿使用它； · 該軟件過程是否可以用于其它項目； · 管理者和開發(fā)人員是否接受過一系列的軟件工程培訓(xùn)； · 是否為每一個軟件開發(fā)者和管理者提供了印好的軟件工程標準； · 是否為作為軟件過程一部分而定義的所有交付物建立了文檔概要及示例； · 是否定期對需求規(guī)約、設(shè)計和編碼進行正式的技術(shù)復(fù)審； · 是否定期對測試過程和測試情況進行復(fù)審； · 是否對每一次正式技術(shù)復(fù)審的結(jié)果建立了文檔，其中包括發(fā)現(xiàn)的錯誤及使用的資源；

14、83; 有什么機制來保證按照軟件工程標準來指導(dǎo)工作； · 是否使用配置管理來維護系統(tǒng)/軟件需求、設(shè)計、編碼、測試用例之間的一致性； · 是否使用一個機制來控制用戶需求的變化及其對軟件的影響； · 對于每一個承包出去的子合同，是否有一份文檔化的工作說明、一份軟件需求規(guī)約和一份軟件開發(fā)計劃； · 是否有一個可遵循的規(guī)程，來跟蹤及復(fù)審子合同承包商的工作； 技術(shù)問題 · 是否使用方便易用的規(guī)格說明技術(shù)來輔助客戶與開發(fā)者之間的通信； · 是否使用特定的方法進行軟件分析； · 是否使用特定的方法進行數(shù)據(jù)和體系結(jié)構(gòu)的設(shè)計； ·

15、是否90以上的代碼都是使用高級語言編寫的； · 是否定義及使用特定的規(guī)則進行代碼編寫； · 是否使用特定的方法進行測試用例的設(shè)計； · 是否使用配置管理軟件工具控制和跟蹤軟件過程中的變化活動； · 是否使用工具來創(chuàng)造軟件原型； · 是否使用軟件工具來支持測試過程； · 是否使用軟件工具來支持文檔的生成和管理； · 是否收集所有軟件項目的質(zhì)量度量值； · 是否收集所有軟件項目的生產(chǎn)率度量值； 如果對于上述問題的答案多數(shù)是否定的，則軟件過程是薄弱的，且風險很高5、技術(shù)風險 突破技術(shù)的極限極具挑戰(zhàn)性和令人興奮，但這也是有

16、風險的。下面的風險檢查表中的條目標識了與建造的技術(shù)相關(guān)的常見風險： · 該技術(shù)對于你的公司而言是新的嗎； · 客戶的需求是否需要創(chuàng)建新的算法或輸入、輸出技術(shù)； · 待開發(fā)的軟件是否需要使用新的或未經(jīng)證實的硬件接口； · 待開發(fā)的軟件是否需要與開發(fā)商提供的未經(jīng)證實的軟件產(chǎn)品接口； · 待開發(fā)的軟件是否需要與功能和性能均未在本領(lǐng)域得到證實的數(shù)據(jù)庫系統(tǒng)接口； · 產(chǎn)品的需求是否要求采用特定的用戶界面； · 產(chǎn)品的需求中是否要求開發(fā)某些程序構(gòu)件，這些構(gòu)件與你的公司以前開發(fā)的構(gòu)件完全不同； · 需求中是否要求采用新的分析、設(shè)

17、計、測試方法； · 需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法； · 需求中是否有過分的對產(chǎn)品的性能約束； · 客戶能確定所要求的功能是可行的嗎？ 如果對于這些問題中的任何一個答案是肯定的，則需要進一步的調(diào)研，以評估潛在地風險。 6、開發(fā)環(huán)境風險 軟件工程環(huán)境支持項目組、過程及產(chǎn)品，但是，如果環(huán)境有缺陷，它就有可能成為重要的風險源。下面的風險檢查表中的條碼標識了與開發(fā)環(huán)境相關(guān)的風險： · 是否有可用的軟件項目管理工具； · 是否有可用的軟件過程管理工具； · 是否有可用的分析及設(shè)計工具； · 分析和設(shè)計工具是否適用于待建造產(chǎn)品；

18、 · 是否有可用的編譯器或代碼生成器； · 是否有可用的測試工具； · 是否有可用的軟件配置管理工具； · 環(huán)境是否利用了數(shù)據(jù)庫或數(shù)據(jù)倉庫； · 項目組的成員是否接受過每個所使用工具的培訓(xùn)； · 是否有專家能夠回答有關(guān)工具的問題; · 工具的聯(lián)機幫助及文檔是否適當； 如果對于上述問題的答案多數(shù)是否定的，則軟件開發(fā)環(huán)境是薄弱的，且風險很高。 7、與人員數(shù)目及經(jīng)驗相關(guān)的風險 · 是否有最優(yōu)秀的人員可用； · 人員在技術(shù)上是否配套； · 是否有足夠的人員可用； · 開發(fā)人員是否能夠自始至終地

19、參加整個項目的工作； · 項目中是否有一些人員只能部分時間工作； · 開發(fā)人員對自己的工作是否有正確的期望； · 開發(fā)人員是否接受過必要的培訓(xùn)； · 開發(fā)人員的流動是否仍能保證工作的連續(xù)性； 如果對于這些問題中的任何一個答案是否定的，則需要進一步的調(diào)研，以評估潛在地風險。8、風險因素和驅(qū)動因子 為了很好地識別和消除軟件風險，項目管理者需要標識影響軟件風險因素的風險驅(qū)動因子，這些因素包括性能、成本、支持和進度。風險因素是以如下的方式定義的： · 性能風險產(chǎn)品能夠滿足需求且符合于其使用目的的不確定的程度。 · 成本風險項目預(yù)算能夠被維持的

20、不確定的程度。 · 支持風險軟件易于糾錯、適應(yīng)及增強的不確定的程度。 · 進度風險項目進度能夠被維持且產(chǎn)品能按時交付的不確定的程度。 每一個風險驅(qū)動因子對風險因素的影響均可分為四個影響類別可忽略的、輕微的、嚴重的、災(zāi)難性的。下表指出了由于錯誤而產(chǎn)生的潛在影響或沒有達到預(yù)期的結(jié)果所產(chǎn)生的潛在影響。影響類別的選擇是以最符合表中描述的特性為基礎(chǔ)的。 影響評估類別因素性能支持成本進度災(zāi)難的1無法滿足需求而導(dǎo)致任務(wù)失敗錯誤將導(dǎo)致進度延遲和成本增加2嚴重退化使得根本無法達到要求的技術(shù)性能無法作出響應(yīng)或無法支持的軟件嚴重的資金短缺，很可能超出預(yù)算無法在交付日期內(nèi)完成嚴重的1無法滿足需求而

21、導(dǎo)致系統(tǒng)性能下降，使得任務(wù)能否成功受到置疑錯誤將導(dǎo)致操作的延遲，并使成本增加2技術(shù)性能有所下降在軟件修改中有少量的延遲資金不足，可能會超支交付日期可能延遲輕微的1無法滿足要求而導(dǎo)致次要任務(wù)的退化成本、影響和即可恢復(fù)的進度上的小問題2技術(shù)性能有較小的降低較好的軟件支持有充足的資金來源實際的、可完成的進度計劃可忽略的1無法滿足要求而導(dǎo)致使用不方便或不易操作錯誤對進度及成本的影響很小2技術(shù)性能不會降低易于進行軟件支持可能低于預(yù)算交付日期將會提前注： 1、未測試出的軟件錯誤或缺陷所產(chǎn)生的潛在影響。 2、如果沒有達到預(yù)期的結(jié)果所產(chǎn)生的潛在影響。五、風險預(yù)測風險預(yù)測，又稱風險估算，試圖從兩個方面評估每一個

22、風險風險發(fā)生的可能性或概率，以及風險發(fā)生了，所產(chǎn)生的后果。項目計劃者、其它管理人員和技術(shù)人員一起執(zhí)行四個風險預(yù)測活動：（1）建立一個尺度，以反映風險發(fā)生的可能性；（2）描述風險的后果；（3）估算風險對項目及產(chǎn)品的影響；（4）標注風險預(yù)測的整體精確度，以免產(chǎn)生誤解。 1、建立風險表 風險表給項目管理者提供了一種簡單的風險預(yù)測技術(shù)。（樣本如下表） 項目組一開始要在表中的第一列列出所有風險可能，這些可以利用前面所述的風險檢查條目來完成。在第二列隊風險進行分類，風險發(fā)生概率放在第三列。每個風險的概率值可以由項目組成員個別估算，然后將這些值平均，得到一個有代表性的概率值。 分類前的風險表樣本風險類別概率

23、影響RMMM規(guī)模估算可能非常低用戶數(shù)量大大超出計劃復(fù)用程度低于計劃最終用戶抵制該計劃交付期限將被緊縮資金將回流失用戶將改變需求技術(shù)達不到預(yù)期的效果缺少對工具的培訓(xùn)人員缺乏經(jīng)驗人員流動頻繁··注：影響類別取值：1災(zāi)難的 2嚴重的 3輕微的 4可忽略的一旦完成風險表的前四列內(nèi)容，就要根據(jù)概率及影響來進行排序。高概率、高影響的風險放在表的上方。這就完成了第一次風險排序。 項目管理者研究已經(jīng)排序的表，并定義一條終止線。該終止線（表中某一點上的一條水平線）表示：只有在那些線上的風險才會得到進一步的關(guān)注，線之下的風險則需要再評估以完成第二次排序。 風險影響及概率從管理的角度來考慮，是起

24、著不同作用的（見下圖）。一個具有高影響但發(fā)生概率很低的風險因素不應(yīng)該花費太多的管理時間。而高影響且發(fā)生概率為中到高的風險以及低影響但高概率的風險，應(yīng)該首先考慮。 2、評估風險影響 如果風險真的發(fā)生了，所產(chǎn)生的后果有三個因素可能會受影響：風險的性質(zhì)、范圍、時間。風險的性質(zhì)是指當風險發(fā)生時可能產(chǎn)生的問題。例如，一個定義得很差的與客戶硬件的接口（技術(shù)風險）會妨礙早期的設(shè)計和測試，也有可能導(dǎo)致項目后期階段的系統(tǒng)集成問題。風險的范圍結(jié)合了嚴重性及其整體分布情況。風險的時間主要考慮何時能夠感到風險，風險會持續(xù)多長時間。在大多數(shù)情況下，項目管理者希望“壞消息”越早出現(xiàn)越好。 以下的步驟用來確定風險的整體影響

25、：· 確定每個風險元素發(fā)生的平均概率。 · 使用前面的表格，基于其中列出的標準來確定每個因素的影響。 · 完成風險表，分析其結(jié)果。 · 風險預(yù)測和分析技術(shù)可以在軟件項目進展過程中跌代使用。項目組定期復(fù)查風險表，再評估每一個風險，以確定新的情況是否引起其概率及影響的改變。 3、風險評估 我們建立如下形式的一系列三元組：r,l,x 其中r表示風險，l表示風險發(fā)生的概率，x表示風險產(chǎn)生的影響。在風險評估過程中，我們進一步審查在風險預(yù)測階段所做的估算的精確度，試圖為所發(fā)現(xiàn)的風險排出優(yōu)先次序，并開始考慮如何控制或避免可能發(fā)生的風險。 要使評估發(fā)生作用，必須定義一個

26、風險參考水平值。對于大多數(shù)軟件項目而言，前面討論的風險因素性能、成本、支持、進度，也代表了風險參考水平值。即，對于性能下降、成本超支、支持困難、或進度延遲，都有一個水平值的要求，超過它就會導(dǎo)致項目被迫停止。如果風險的組合所產(chǎn)生的問題引起一個或多個參考水平值被超過，則工作將會停止。在軟件風險分析中，風險參考水平值存在一個點，稱為參考點或臨界點，在這個點上，決定繼續(xù)進行該項目或終止它（問題太多）都是可以接受的。 下圖以圖形方式表示了這種情況。如果風險的組合產(chǎn)生問題導(dǎo)致成本超支及進度延遲，則會有一個水平值,即圖中的曲線，當超過它時會引起項目終止。實際上，參考水平很少能表示成光滑曲線。在大多數(shù)情況下，

27、它是一個區(qū)域，其中存在很多不確定性。 因此，在風險評估中，我們執(zhí)行以下步驟： · 定義項目的風險參考水平值； · 建立每一組r,l,x與每一個參考水平值之間的關(guān)系； · 預(yù)測一組臨界點以定義項目終止區(qū)域，該區(qū)域由一條曲線或不確定區(qū)域界定。 · 預(yù)測什么樣的風險組合會影響參考水平值。六、風險緩解、監(jiān)控和管理進一步的所有風險分析活動都只有一個目的輔助項目組建立處理風險的策略。一個有效的策略必須考慮三個問題： · 風險避免 · 風險監(jiān)控 · 風險管理及意外事件計劃 如果軟件項目組對于風險采取主動的方法，則避免永遠是最好的策略。這可

28、以通過建立一個風險緩解計劃來達到。例如，頻繁的人員流動被標注為一個項目風險，基于以往的歷史和管理經(jīng)驗，人員流動的概率為70，而影響被預(yù)測衛(wèi)對于項目成本及進度有嚴重的影響。為了緩解這個風險，項目管理者必須建立一個策略來降低人員流動?？赡懿扇〉牟呗匀缦拢?· 與現(xiàn)有人員一起探討一下人員流動的原因（如惡劣的工作條件，低報酬，競爭激烈） · 在項目開始之前，采取行動以緩解那些在管理控制之下的原因。 · 一旦項目啟動，假設(shè)會發(fā)生人員流動并采取一些技術(shù)措施以保證當人員離開時的工作連續(xù)性。 · 對項目進行良好組織，使得每一個開發(fā)活動的信息能被廣泛傳播和交流。 

29、3; 定義文檔的標準，并建立相應(yīng)的機制，以確保文檔能被及時建立。 · 對所有工作進行詳細復(fù)審，使得不止一個人熟悉該項工作。 · 對于每一個關(guān)鍵的技術(shù)人員都指定一個后備人員。 隨著項目的進展，風險監(jiān)控活動開始進行。項目管理者監(jiān)控某些因素，這些因素可以提供風險是否正在變高或變低的指示。在上例中，應(yīng)該監(jiān)控下列因素： · 項目組成員對項目壓力的一般態(tài)度。 · 項目組的凝聚力。 · 項目組成員彼此之間的關(guān)系。 · 與報酬和利益相關(guān)的潛在問題 · 在公司內(nèi)及公司外工作的可能性。 除了監(jiān)控上述因素之外，項目管理者還應(yīng)該監(jiān)控風險緩解步驟的效力。例如：上例中，風險緩解步驟要求定義“文檔的標準，并建立相應(yīng)的機制，以確保文檔能被及時建立”。如果有關(guān)鍵的人物離開了項目組，這是保證工作連續(xù)性的機制。項目管理者應(yīng)該仔細地監(jiān)控這些文檔，以保證文檔內(nèi)容正確，當新員工加入該項目時，能為他們提供必要的信息。 風險管理及意外事件計劃假設(shè)緩解工作已經(jīng)失敗，風險變成了現(xiàn)實。繼續(xù)前面的例子，假定項目正在進行中，有一些人宣布將要離開。如果按照緩解策略行事，則有后備人員可用，因為信息已經(jīng)文檔化，有關(guān)知識已經(jīng)在項目組中廣泛進行了交流。此外，項目管理者還可以暫時重新