軟件項目風(fēng)險管理(風(fēng)險識別、預(yù)測、評估、緩解、監(jiān)控)

1、閱讀使人充實，會談使人敏捷，寫作使人精確。培根軟件項目風(fēng)險管理一、風(fēng)險管理概述軟件風(fēng)險是指軟件開發(fā)過程中及軟件產(chǎn)品本身可能造成的傷害或損失。風(fēng) 險關(guān)注未來的事情，這意味著，風(fēng)險涉及選擇及選擇本身包含的不確定性， 在軟 件開發(fā)過程及軟件產(chǎn)品都要面臨各種決策的選擇。風(fēng)險是介于確定性和不確定性之間的狀 態(tài)，是處于無知和完整知識之間的狀態(tài)。另一方面，風(fēng)險將涉及思想、觀念、行為、地點 等因素的改變。當(dāng)在軟件工程領(lǐng)域考慮風(fēng)險時，我們要關(guān)注以下的問題：什么樣的風(fēng)險會導(dǎo)致軟件項目的徹底失?。坑脩粜枨?、開發(fā)技術(shù)、目標計算機、以及所有其它與項目有關(guān) 的因素的改變將會對按時交付和總體成功產(chǎn)生什么影響？對于采用什么方

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

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

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

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

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

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

8、參與工作的軟件工程師的總體技術(shù)水平及項目經(jīng)驗相關(guān)的風(fēng) 險。風(fēng)險條目檢查表能夠以不同的方式來組織。與上述話題相關(guān)的問題可以由每一個軟 件項目來回答。這些問題的答案使得計劃者能夠估算風(fēng)險產(chǎn)生的影響。1、產(chǎn)品規(guī)模風(fēng)險項目風(fēng)險是直接與產(chǎn)品規(guī)模成正比的。下面的風(fēng)險檢查表中的條目標識了產(chǎn)品（軟 件）規(guī)模相關(guān)的常見風(fēng)險：* 是否以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ù)有多少；* 產(chǎn)品的需求改變多少？交付之前有多少？交付之

9、后有多少？* 復(fù)用的軟件有多少？2、商業(yè)影響風(fēng)險銷售部門是受商業(yè)驅(qū)動的，而商業(yè)考慮有時會直接與技術(shù)實現(xiàn)發(fā)生沖突。下面的風(fēng)險檢查表中的條目標識了與商業(yè)影響相關(guān)的常見風(fēng)險： 本產(chǎn)品對公司的收入有何影響； 本公司是否得到公司高級管理層的重視； 交付期限的合理性如何； 將會使用本產(chǎn)品的用戶數(shù)及本產(chǎn)品是否與用戶的需要相符合； 本產(chǎn)品必須能與之互操作的其它產(chǎn)品/系統(tǒng)的數(shù)目； 最終用戶的水平如何； 政府對本產(chǎn)品開發(fā)的約束； 延遲交付所造成的成本消耗是多少； 產(chǎn)品缺陷所造成的成本消耗是多少；對于待開發(fā)產(chǎn)品的每一個回答都必須與過去的經(jīng)驗加以比較。如果出現(xiàn)了較大的百 分比偏差或者如果數(shù)字接近過去很不令人滿意的結(jié)果

10、，則風(fēng)險較高。 、客戶相關(guān)風(fēng)險客戶有不同的需要。一些人只知道他們需要什么；而另一些人知道他們不需要什 么。一些客戶希望進行詳細的討論，而另客戶則滿足于模糊的承諾。客戶有不同的個性。一些人喜歡享受客戶的身份，而另一些人則根本不喜歡做為客 戶。一些人會高興地接受幾乎任何交付的產(chǎn)品，并能充分利用一個不好的產(chǎn)品；而另一 些人則會對質(zhì)量差的產(chǎn)品猛烈抨擊。一些人會對質(zhì)量好的產(chǎn)品表示贊賞；而另一些人則 不管怎樣都抱怨不休?？蛻艉凸?yīng)商之間也有各種不同的通信方式。一些人非常熟悉產(chǎn)品及生產(chǎn)廠商；而 另一些人則可能素未謀面，僅僅通過信件來往和電話與生產(chǎn)廠商溝通。一個不好的”客戶可能會對一個軟件項目組能否在預(yù)算內(nèi)完

11、成項目產(chǎn)生很大的影 響。對于項目管理者而言，不好的客戶是對項目計劃的巨大威脅和實際的風(fēng)險。下面的風(fēng) 險檢查表中的條目標識了與客戶特征相關(guān)的常見風(fēng)險：學(xué)問是異常珍貴的東西，從任何源泉吸收都不可恥。阿卜日法拉茲閱讀使人充實，會談使人敏捷，寫作使人精確。培根 你以前是否曾與這個客戶合作過； 該客戶是否很清楚需要什么；他能否化時間把需求寫出來； 該客戶是否同意花時間召開正式的需求收集會議，以確定項目范圍； 該客戶是否愿意建立與開發(fā)者之間的快速通信渠道； 該客戶是否愿意參加復(fù)審工作； 該客戶是否具有改產(chǎn)品領(lǐng)域的技術(shù)素養(yǎng)； 該客戶是否愿意你的人來做他們的工作； 該客戶是否了解軟件過程；如果對于這些問題中的

12、任何一個答案是否定的，則需要進一步的調(diào)研，以 評估潛在 地風(fēng)險。4、過程風(fēng)險如果軟件過程定義得不清楚；如果分析、設(shè)計、測試以無序的方式進行；如果質(zhì)量 是每個人都認為很重要的概念，但沒有人切實采取行動來保證它，那么這個項目就處在 風(fēng)險之中。過程問題：*高級管理層是否有一份已經(jīng)寫好的政策陳述，該陳述中強調(diào)了軟件開發(fā)標準過程 的重要性；* 開發(fā)組織是否已經(jīng)擬定了一份已經(jīng)成文的、用于本項目開發(fā)的軟件過程的說明；* 開發(fā)人員是否同意按照文檔所寫的軟件過程進行開發(fā)工作，并自愿使用 它；* 該軟件過程是否可以用于其它項目；* 管理者和開發(fā)人員是否接受過一系列的軟件工程培訓(xùn)；是否為每一個軟件開發(fā)者和管理者提供

13、了印好的軟件工程標準；* 是否為作為軟件過程一部分而定義的所有交付物建立了文檔概要及示例；* 是否定期對需求規(guī)約、設(shè)計和編碼進行正式的技術(shù)復(fù)審；* 是否定期對測試過程和測試情況進行復(fù)審； 是否對每一次正式技術(shù)復(fù)審的結(jié)果建立了文檔，其中包括發(fā)現(xiàn)的錯誤及使用的資 源； 有什么機制來保證按照軟件工程標準來指導(dǎo)工作； 是否使用配置管理來維護系統(tǒng)/軟件需求、設(shè)計、編碼、測試用例之間的一致性； 是否使用一個機制來控制用戶需求的變化及其對軟件的影響；*對于每一個承包出去的子合同，是否有一份文檔化的工作說明、一份軟件 需求規(guī)約 和一份軟件開發(fā)計劃；.是否有一個可遵循的規(guī)程，來跟蹤及復(fù)審子合同承包商的工作；技術(shù)

14、問題 是否使用方便易用的規(guī)格說明技術(shù)來輔助客戶與開發(fā)者之間的通信； 是否使用特定的方法進行軟件分析； 是否使用特定的方法進行數(shù)據(jù)和體系結(jié)構(gòu)的設(shè)計； 是否90 %以上的代碼都是使用高級語言編寫的； 是否定義及使用特定的規(guī)則進行代碼編寫； 是否使用特定的方法進行測試用例的設(shè)計；*是否使用配置管理軟件工具控制和跟蹤軟件過程中的變化活動；是否使用工具來創(chuàng)造軟件原型； 是否使用軟件工具來支持測試過程； 是否使用軟件工具來支持文檔的生成和管理； 是否收集所有軟件項目的質(zhì)量度量值； 是否收集所有軟件項目的生產(chǎn)率度量值；如果對于上述問題的答案多數(shù)是否定的，則軟件過程是薄弱的，且風(fēng)險很高5、技術(shù)風(fēng)險突破技術(shù)的極

15、限極具挑戰(zhàn)性和令人興奮，但這也是有風(fēng)險的。下面的風(fēng)險檢查表中 的條目標識了與建造的技術(shù)相關(guān)的常見風(fēng)險： 該技術(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è)計、測試方法； 需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法； 需求中是否有

16、過分的對產(chǎn)品的性能約束； 客戶能確定所要求的功能是可行的嗎？如果對于這些問題中的任何一個答案是肯定的，則需要進一步的調(diào)研，以評估潛在 地風(fēng)險。6、開發(fā)環(huán)境風(fēng)險軟件工程環(huán)境支持項目組、過程及產(chǎn)品，但是，如果環(huán)境有缺陷，它就有可能成為 重要的風(fēng)險源。下面的風(fēng)險檢查表中的條碼標識了與開發(fā)環(huán)境相關(guān)的風(fēng) 險： 是否有可用的軟件項目管理工具； 是否有可用的軟件過程管理工具； 是否有可用的分析及設(shè)計工具； 分析和設(shè)計工具是否適用于待建造產(chǎn)品； 是否有可用的編譯器或代碼生成器； 是否有可用的測試工具； 是否有可用的軟件配置管理工具； 環(huán)境是否利用了數(shù)據(jù)庫或數(shù)據(jù)倉庫； 項目組的成員是否接受過每個所使用工具的培訓(xùn)

17、； 是否有專家能夠回答有關(guān)工具的問題； 工具的聯(lián)機幫助及文檔是否適當(dāng)；如果對于上述問題的答案多數(shù)是否定的，則軟件開發(fā)環(huán)境是薄弱的，且風(fēng)險很圖。7、與人員數(shù)目及經(jīng)驗相關(guān)的風(fēng)險 是否有最優(yōu)秀的人員可用； 人員在技術(shù)上是否配套； 是否有足夠的人員可用； 開發(fā)人員是否能夠自始至終地參加整個項目的工作； 項目中是否有一些人員只能部分時間工作； 開發(fā)人員對自己的工作是否有正確的期望； 開發(fā)人員是否接受過必要的培訓(xùn)； 開發(fā)人員的流動是否仍能保證工作的連續(xù)性；如果對于這些問題中的任何一個答案是否定的，則需要進一步的調(diào)研，以評估潛在 地風(fēng)險。8、風(fēng)險因素和驅(qū)動因子為了很好地識別和消除軟件風(fēng)險，項目管理者需要標識

18、影響軟件風(fēng)險因素的風(fēng)險驅(qū) 動因子，這些因素包括性能、成本、支持和進度。風(fēng)險因素是以如下的方式定義的：* 性能風(fēng)險一一產(chǎn)品能夠滿足需求且符合于其使用目的的不確定的程度。* 成本風(fēng)險一一項目預(yù)算能夠被維持的不確定的程度。* 支持風(fēng)險一一軟件易于糾錯、適應(yīng)及增強的不確定的程度。* 進度風(fēng)險一一項目進度能夠被維持且產(chǎn)品能按時交付的不確定的程度。每一個風(fēng)險驅(qū)動因子對風(fēng)險因素的影響均可分為四個影響類別一一可忽略 的、輕微 的、嚴重的、災(zāi)難性的。下表指出了由于錯誤而產(chǎn)生的潛在影響或沒有 達到預(yù)期的結(jié)果所 產(chǎn)生的潛在影響。影響類別的選擇是以最符合表中描述的特性為基礎(chǔ)的。影響評估類別'因素性能支持成本進

19、度1無法滿足需求而導(dǎo)致任務(wù)失敗錯誤將導(dǎo)致進度延遲和成本增加災(zāi)難的2嚴重退化使得 根本無法達到 要求的技術(shù)性 能無法作出響應(yīng)或無法支持的軟件嚴重的資金短缺，很可能超出預(yù)算無法在交付日期內(nèi)完成嚴重的1無法滿足需求而導(dǎo)致系統(tǒng)性能下降，使得任務(wù)能否成功受到置疑錯誤將導(dǎo)致操作的延遲，并使成本增加2技術(shù)性能有所卜降在軟件修改中有少量的延遲資金不足，可能會超支交付日期可能延遲輕微的1無法滿足要求而導(dǎo)致次要任務(wù)的退化成本、影響和即可恢復(fù)的進度上的小問題2技術(shù)性能有較小的降低較好的軟件支持有充足的資金來源實際的、可完成的進度計劃無法滿足要求而導(dǎo)致使用不方便或不可忽略1易操作午苜俁對世度反收企網(wǎng)影啊儂小的2技術(shù)性

20、能不會降低易于進行軟件支持可能低于預(yù)算交付日期將會提前注：1、未測試出的軟件錯誤或缺陷所產(chǎn)生的潛在影響。2、如果沒有達到預(yù)期的結(jié)果所產(chǎn)生的潛在影響。五、風(fēng)險預(yù)測風(fēng)險預(yù)測，又稱風(fēng)險估算，試圖從兩個方面評估每一個風(fēng)險一一風(fēng)險發(fā)生的可能性或概率，以及風(fēng)險發(fā)生了，所產(chǎn)生的后果。項目計劃者、其它管理人員和技術(shù)人 員一起執(zhí)行四個風(fēng)險預(yù)測活動：(1)建立一個尺度，以反映風(fēng)險發(fā)生的可能性；(2)描述風(fēng)險的后果；(3)估算風(fēng)險對項目及產(chǎn)品的影響；(4)標注風(fēng)險預(yù)測的整體精確度，以免產(chǎn)生誤解。1、建立風(fēng)險表風(fēng)險表給項目管理者提供了一種簡單的風(fēng)險預(yù)測技術(shù)。(樣本如下表)項目組一開始要在表中的第一列列出所有風(fēng)險可能，

21、這些可以利用前面所述的風(fēng)險 檢查條目來完成。在第二列隊風(fēng)險進行分類，風(fēng)險發(fā)生概率放在第三列。每個風(fēng)險的概率 值可以由項目組成員個別估算，然后將這些值平均，得到一個有代表性的概率值。分類前的風(fēng)險表樣本風(fēng)險類別概率影響RMMM規(guī)模估算可能非常低PS6 0%2用戶數(shù)量大大超出計劃PS3 0%3復(fù)用程度低于計劃PS7 0%2最終用戶抵制該計劃BU4 0%3交付期限將被緊縮BU5 0%2資金將回流失CU4 0%1用戶將改變需求PS8 0%2技術(shù)達不到預(yù)期的效果TE3 0%1缺少對工具的培訓(xùn)DE8 0%3人員缺乏經(jīng)驗ST3 0%2人員流動頻繁ST6 0%2注：影響類別取值：1 災(zāi)難的2嚴重的3 輕微的4

22、可忽略的一旦完成風(fēng)險表的前四列內(nèi)容，就要根據(jù)概率及影響來進行排序。高概率、高影響 的風(fēng)險放在表的上方。這就完成了第一次風(fēng)險排序。項目管理者研究已經(jīng)排序的表，并定義一條終止線。該終止線（表中某一點上的一 條水平線）表示：只有在那些線上的風(fēng)險才會得到進一步的關(guān)注，線之下的風(fēng)險則需要 再評估以完成第二次排序。風(fēng)險影響及概率從管理的角度來考慮，是起著不同作用的（見下圖）。一個具有高影響但發(fā)生概率很低的風(fēng)險因素不應(yīng)該花費太多的管理時間。而高影響且發(fā)生概率為中到高的風(fēng)險以及低影響但高概率的風(fēng)險，應(yīng)該首先考慮。很高可忽略的 風(fēng)隱因素管理的考能學(xué)問是異常珍貴的東西，從任何源泉吸收都不可恥。阿卜日法拉茲2、評估

23、風(fēng)險影響如果風(fēng)險真的發(fā)生了，所產(chǎn)生的后果有三個因素可能會受影響：風(fēng)險的性 質(zhì)、范圍、時間。風(fēng)險的性質(zhì)是指當(dāng)風(fēng)險發(fā)生時可能產(chǎn)生的問題。例如，一個定義得很 差的與客戶硬件的接口（技術(shù)風(fēng)險）會妨礙早期的設(shè)計和測試，也有可能導(dǎo)致項目后期 階段的系統(tǒng)集成問題。風(fēng)險的范圍結(jié)合了嚴重性及其整體分布情況。風(fēng)險的時間主要考 慮何時能夠感到風(fēng)險，風(fēng)險會持續(xù)多長時間。在大多數(shù)情況下，項目管理者希望壞消息 '越早出現(xiàn)越好。以下的步驟用來確定風(fēng)險的整體影響： 確定每個風(fēng)險元素發(fā)生的平均概率。 使用前面的表格，基于其中列出的標準來確定每個因素的影響。 完成風(fēng)險表，分析其結(jié)果。 風(fēng)險預(yù)測和分析技術(shù)可以在軟件項目進展

24、過程中跌代使用。項目組定期復(fù)查風(fēng)險表，再評估每一個風(fēng)險，以確定新的情況是否引起其概率及影響的改變。3、風(fēng)險評估我們建立如下形式的一系列三元組：其中r表示風(fēng)險1表示風(fēng)險發(fā)生的概率，x表示風(fēng)險產(chǎn)生的影響。在風(fēng)險評估過 程中，我們進一步審查在風(fēng)險預(yù)測階段所做的估算的精確度，試圖為所發(fā)現(xiàn)的風(fēng)險排出 優(yōu)先次序，并開始考慮如何控制或避免可能發(fā)生的風(fēng)險。要使評估發(fā)生作用，必須定義一個風(fēng)險參考水平值。對于大多數(shù)軟件項目而言，前 面討論的風(fēng)險因素一一，性能、成本、支持、進度，也代表了風(fēng)險參考水平值。即，對于 性能下降、成本超支、支持困難、或進度延遲，都有一個水平值的要求，超過它就會導(dǎo) 致項目被迫停止。如果風(fēng)險的

25、組合所產(chǎn)生的問題引起一個或多個參考水平值被超過，則 工作將會停止。在軟件風(fēng)險分析中，風(fēng)險參考水平值存在一個點，稱為參考點或臨界 點，在這個點上，決定繼續(xù)進行該項目或終止它（問題太多）都是可以接受的。下圖以圖形方式表示了這種情況。如果風(fēng)險的組合產(chǎn)生問題導(dǎo)致成本超支及進度延 遲，則會有一個水平值,即圖中的曲線，當(dāng)超過它時會引起項目終止。實際上，參考水平很少能表示成光滑曲線。在大多數(shù)情況下，它是一個區(qū)域，其中存在很多不確定性。因此，在風(fēng)險評估中，我們執(zhí)行以下步驟：定義項目的風(fēng)險參考水平值；建立每一組與每一個參考水平值之間的關(guān)系；*預(yù)測一組臨界點以定義項目終止區(qū)域，該區(qū)域由一條曲線或不確定區(qū)域界,預(yù)測

26、什么樣的風(fēng)險組合會影響參考水平值。六、風(fēng)險緩解、監(jiān)控和管理進一步的所有風(fēng)險分析活動都只有一個目的一一輔助項目組建立處理風(fēng)險的策 略。一個有效的策略必須考慮三個問題： 風(fēng)險避免 風(fēng)險監(jiān)控 風(fēng)險管理及意外事件計劃如果軟件項目組對于風(fēng)險采取主動的方法，則避免永遠是最好的策略。這 可以通過 建立一個風(fēng)險緩解計劃來達到。例如，頻繁的人員流動被標注為一個項目風(fēng)險，基于以 往的歷史和管理經(jīng)驗，人員流動的概率為70 %，而影響被預(yù)測衛(wèi)對于項目成本及進度有嚴重的影響。為了緩解這個風(fēng)險，項目管理者必須建立一個策 略來降低人員流動?？赡懿扇〉牟呗匀缦拢?與現(xiàn)有人員一起探討一下人員流動的原因（如惡劣的工作條件，低報酬

27、， 競爭激烈） 在項目開始之前，采取行動以緩解那些在管理控制之下的原因。 一旦項目啟動，假設(shè)會發(fā)生人員流動并采取一些技術(shù)措施以保證當(dāng)人員離開時的工 作連續(xù)性。 對項目進行良好組織，使得每一個開發(fā)活動的信息能被廣泛傳播和交流。 定義文檔的標準，并建立相應(yīng)的機制，以確保文檔能被及時建立。 對所有工作進行詳細復(fù)審，使得不止一個人熟悉該項工作。 對于每一個關(guān)鍵的技術(shù)人員都指定一個后備人員。隨著項目的進展，風(fēng)險監(jiān)控活動開始進行。項目管理者監(jiān)控某些因素，這 些因素可以提供風(fēng)險是否正在變高或變低的指示。在上例中，應(yīng)該監(jiān)控下列因素： 項目組成員對項目壓力的一般態(tài)度。 項目組的凝聚力。 項目組成員彼此之間的關(guān)系

28、。4與報酬和利益相關(guān)的潛在問題 在公司內(nèi)及公司外工作的可能性。除了監(jiān)控上述因素之外，項目管理者還應(yīng)該監(jiān)控風(fēng)險緩解步驟的效力。例 如：上例 中，風(fēng)險緩解步驟要求定義文檔的標準，并建立相應(yīng)的機制，以確保 文檔能被及時建 立”。如果有關(guān)鍵的人物離開了項目組，這是保證工作連續(xù)性的 機制。項目管理者應(yīng)該 仔細地監(jiān)控這些文檔，以保證文檔內(nèi)容正確，當(dāng)新員工加 入該項目時，能為他們提供必 要的信息。風(fēng)險管理及意外事件計劃假設(shè)緩解工作已經(jīng)失敗，風(fēng)險變成了現(xiàn)實。繼續(xù)前面的例 子，假定項目正在進行中，有一些人宣布將要離開。如果按照緩解策略行事，則有后備 人員可用，因為信息已經(jīng)文檔化，有關(guān)知識已經(jīng)在項目組中廣泛進行了交流。此外，項 目管理者還可以暫時重新將資源調(diào)整到那些需要人的地方去，并調(diào)整項目進度，從而使 新加入的成員能夠趕上進度”。同時，要求那些要離開的人員停止工作，進入知識交接模式”