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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15、限極具挑戰(zhàn)性和令人興奮，但這也是有風險的。下面的風險檢查表中 的條目標識了與建造的技術相關的常見風險： 該技術對于你的公司而言是新的嗎； 客戶的需求是否需要創(chuàng)建新的算法或輸入、輸出技術； 待開發(fā)的軟件是否需要使用新的或未經證實的硬件接口； 待開發(fā)的軟件是否需要與開發(fā)商提供的未經證實的軟件產品接口； 待開發(fā)的軟件是否需要與功能和性能均未在本領域得到證實的數據庫系 統(tǒng)接口 ； 產品的需求是否要求采用特定的用戶界面； 產品的需求中是否要求開發(fā)某些程序構件，這些構件與你的公司以前開發(fā)的構件 完全不同； 需求中是否要求采用新的分析、設計、測試方法； 需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法； 需求中是否有

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

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

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

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

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

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

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

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

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

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

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

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

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