第18章軟件工程風險管理

1、第18章 軟件工程風險管理 第18章 軟件工程風險管理18.1 軟件風險軟件風險18.2 風險識別風險識別18.3 風險預測風險預測 18.4 風險緩解、監(jiān)控與管理風險緩解、監(jiān)控與管理18.5 RMMM計劃計劃 18.6 小結小結 第18章 軟件工程風險管理 18.1 軟軟 件件 風風 險險 對軟件風險的嚴格定義還存在著很多爭議，但對于在風險中包含了兩個特性這一點上已經達成了共識。 (1) 不確定性：風險可能發(fā)生也可能不發(fā)生，即不存在發(fā)生概率為100%的風險(100%會發(fā)生的風險實際上是加在項目上的約束)。 (2) 危害性：一旦風險變成了現實，就會產生惡性后果或損失。 第18章 軟件工程風險管

2、理 進行風險分析時，重要的是量化不確定性的程度和與每個風險相關的損失程度。為了達到此目的，必須考慮不同類型的風險。 項目風險威脅到項目計劃。也就是說，如果項目風險變成現實，可能會拖延項目進度且增加項目的成本。項目風險是指潛在的預算、進度、人力(工作人員及組織)、資源、客戶及需求等方面的問題以及它們對軟件項目的影響。項目的復雜性、規(guī)模及結構不確定性也被定義為項目(估算)風險因素。第18章 軟件工程風險管理 技術風險威脅到要開發(fā)軟件的質量和交付時間。如果技術風險變成現實，則開發(fā)工作可能變得很困難或者根本不可能。技術風險是指潛在的設計、實現、接口、驗證和維護等方面的問題。此外，需求規(guī)約的二義性，技術

3、的不確定性，陳舊的技術及“先進的”技術也是風險因素。技術風險的發(fā)生是因為問題比我們所設想的更難以解決。第18章 軟件工程風險管理 商業(yè)風險威脅到要開發(fā)的軟件的生存能力。商業(yè)風險常常會危害項目或產品。五個主要的商業(yè)風險是： 市場風險：開發(fā)了一個沒有人真正需要的優(yōu)秀產品或系統(tǒng)。 策略風險：開發(fā)的產品不再符合公司的整體商業(yè)策略。 營銷風險：生產了一個銷售部門不知道如何去賣的產品。 管理風險：由于重點的轉移或人員的變動，失去了高級管理層的支持。 預算風險：沒有得到預算或人力上的保證。 第18章 軟件工程風險管理 另一種分類方式將風險分為三類： 已知風險：通過仔細評估項目計劃，開發(fā)項目的商業(yè)及技術環(huán)境以

4、及其他可靠的消息來源(如不現實的交付時間，惡劣的開發(fā)環(huán)境，沒有需求或者軟件范圍文檔)之后可以發(fā)現的那些風險。 可預測風險：能夠從過去項目的經驗中推斷出來(如人員調整、與客戶無法溝通、開發(fā)人員精力分散)的風險。 不可預測風險：可能或有時真會出現的風險，但事先很難識別出來。第18章 軟件工程風險管理 18.2 風風 險險 識識 別別 風險識別就是要識別屬于前述類型中的某些特定的風險。方法是利用一組問卷來幫助項目計劃人員了解在項目和技術方面有哪些風險。Boehm建議使用一個“風險項目檢查表”列出所有可能的與每一個風險因素有關的提問。例如，管理人員或計劃人員可以通過回答下列問題得到對有關人力風險的認識

5、：可用人員是最優(yōu)秀的嗎？按照技能對人員進行了合理組合嗎？人力足夠嗎？第18章 軟件工程風險管理 整個項目開發(fā)期間人員如何投入？有多少人不是全工時投入本項目的工作？人們對于手頭上的工作是否有正確的目標？項目成員是否接受過必要的培訓？項目的成員是否是穩(wěn)定的和連續(xù)的？第18章 軟件工程風險管理 對于這些提問，通過判定分析或假設分析，給出確定的回答，就可以幫助管理人員或計劃人員估算風險的影響。當然，上面僅僅是針對人力資源風險有效的問題。同樣地，我們也可以對其他類型的風險制定出必要的問題，利用和上述方法相同的手段，估算不同類別風險的影響。例如，針對技術風險的問題包括： 該技術對你的組織來說是新的嗎？ 客

6、戶的需求是否需要創(chuàng)建新的算法或I/O技術？ 軟件是否需要使用新的或未經證實的硬件接口？第18章 軟件工程風險管理 待開發(fā)軟件是否要和開發(fā)商提供的未經證實的軟件接口？ 待開發(fā)軟件是否要和其功能和性能均未在本領域中得到證實的數據庫系統(tǒng)接口？ 產品的需求中是否包括要求采用特定的用戶界面？ 產品的需求中是否要求開發(fā)某些程序構件，這些構件和你的組織從前開發(fā)過的構件完全不同？ 需求中是否要求使用新的分析、設計或測試方法？第18章 軟件工程風險管理 需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法，如形式化方法，人工神經網絡方法？ 需求中對產品性能的約束是否過分嚴格？ 客戶能確定所要求的功能是“可行的”嗎？ 如果對于

7、上列問題中任何一個問題的回答是肯定的，則需要進行進一步的調研來評估潛在的風險。第18章 軟件工程風險管理 18.3 風風 險險 預預 測測 風險預測又稱為風險估算。它試圖從兩個方面去評價每一個風險：其一是風險發(fā)生的可能性或概率；其二是如果風險發(fā)生了會造成的后果。風險預測活動要進行四項工作： (1) 建立一個尺度，以反映風險發(fā)生的可能性(尺度可以是布爾值、定性的或定量的)。 (2) 描述風險的后果。 (3) 估算風險對項目和產品的影響。 (4) 標注風險整體預測的精確度以免產生誤解。第18章 軟件工程風險管理 18.3.1 建立風險表建立風險表表表18.1 風險預測表樣本風險預測表樣本風險描述風

8、險類別發(fā)生概率可能的影響RMMM規(guī)模估算可能非常低產品規(guī)模60%2 用戶數量大大超過計劃產品規(guī)模30%3 復用程度低于計劃產品規(guī)模70%2最終用戶抵制該系統(tǒng)商業(yè)風險40%3 交付期限緊縮商業(yè)風險50%2 第18章 軟件工程風險管理 資金流失預算風險40%1 需求改變產品規(guī)模80%2 技術達不到預期效果技術風險30%1 缺少對于工具的培訓人力風險80%3 人員缺乏經驗人力風險30%2 人員流動頻繁人力風險60%2 表表18.1 風險預測表樣本風險預測表樣本第18章 軟件工程風險管理 在表18.1中，影響類別取值為1：災難的；2：嚴重的；3：輕微的；4：可以忽略的。項目組將所有可能的風險都在第一列

9、中列出，在第二列上加以分類。發(fā)生概率經評估后取評估均值，將估計的影響程度填入第四列，然后按照發(fā)生概率和影響程度自高到低地對風險表進行第一次風險排序。 管理者研究已經排序的風險表，定義一條中止線，一般來說，管理者對于中止線以上的風險會進行進一步的關注。其他的風險需要再次評估以完成第二次排序。第18章 軟件工程風險管理 圖18.1 風險和管理的考慮第18章 軟件工程風險管理 風險表中所有在終止線以上的風險都應當進行管理。在表的最后一列包含有一個指針，指向為所有終止線以上的風險制定的風險緩解、監(jiān)控和管理計劃(RMMM計劃，Risk Mitigation，Monitoring and Manageme

10、nt Plan)。 第18章 軟件工程風險管理 18.3.2 風險評估風險評估 建立一個三元組集合來進行風險評估：Ri，Li，Xi其中，Ri是風險，Li是風險出現的可能性，Xi是風險出現會造成的影響。在進行風險評估時，應當進一步檢驗在風險預測時得到的估計的準確性(影響及概率)，試圖為已被發(fā)現的風險排出優(yōu)先順序，并開始考慮如何控制或避免可能發(fā)生的風險。第18章 軟件工程風險管理 要使評估發(fā)生作用，必須定義一個風險參考水平值。對于大多數軟件項目而言，前面所討論的風險因素性能、成本、支持及進度也代表了風險參考水平值，即對于性能下降、成本超支、支持困難、進度延遲(或者它們的組合)都有一個水平值的要求。

11、超出水平值就會導致項目被迫終止。如果風險的組合所產生的問題引起一個或多個參考水平值被超過，則工作將會停止。在軟件風險分析中，風險參考水平值存在一個點，稱為參考點或臨界點。在這個點上，決定繼續(xù)進行某項目或者是終止它(問題太大了)都是可以接受的。圖18.2中就表示了這種情況。如果風險組合產生的問題導致成本超支及進度延遲，則會有一個水平值，(即圖中的曲線)，當超過它時會引起項目終止。第18章 軟件工程風險管理 圖18.2 風險參考水平曲線第18章 軟件工程風險管理 實際上參考水平值很少能夠表示成如圖18.2所示的光滑曲線。在大多數情況下，它是一個區(qū)域，其中存在很多不確定性，這個區(qū)域可能是一個易變區(qū)域

12、。在這些區(qū)域中想要做出基于參考值組合的管理判斷往往是非常困難的。因此，在作風險評估時，可以采用下面的步驟執(zhí)行： (1) 為項目定義風險參照水準。 (2) 嘗試找出在每一個Ri，Li，Xi 和每一個參照水準之間的關系。 (3) 預測參照點組以定義一個終止區(qū)域，用一條曲線或一些易變動區(qū)域來界定。 (4) 努力預測復合的風險組合將如何形成一個參照水準。 第18章 軟件工程風險管理 18.4 風險緩解、監(jiān)控與管理風險緩解、監(jiān)控與管理 在這一步的工作中，所有的風險分析活動都只有一個目的，那就是輔助項目建立處理風險的策略。任何一種有效的策略都必須考慮三個問題：風險避免、風險監(jiān)控、風險管理及意外事件計劃。

13、如果項目組對于風險采取主動策略，則最好的方法是通過制定一個風險緩解計劃并付諸實施，設法避免風險。圖18.3所示為風險緩解與監(jiān)控。第18章 軟件工程風險管理 圖18.3 風險緩解與監(jiān)控第18章 軟件工程風險管理 例如人員頻繁流動是軟件開發(fā)組織中的一個普遍存在的風險。將其標注為R0，基于以往的歷史數據和管理經驗，發(fā)生概率L0被估算為0.7，影響X0被預測為對于項目的成本和進度有極嚴重的影響。 為了緩解這一風險，項目管理者可以采取如下的策略來降低人員流動： (1) 預先與現有人員一同探討一下人員流動的原因(如工作條件惡劣、低報酬、激烈的人才競爭)。 (2) 在項目開始之前，采取行動來緩解那些被識別出

14、的、且在管理控制之下的原因。第18章 軟件工程風險管理 (3) 一旦項目啟動，假設人員會發(fā)生流動，并采取一些措施以保證當人員離開時工作的連續(xù)性。 (4) 對項目組進行良好的組織，使得每一個開發(fā)活動的信息能夠被廣泛地傳播和交流。 (5) 定義文檔的標準，并建立保證文檔能夠被及時、正確建立的機制。 (6) 對所有的工作進行詳細的復審，保證不止一個人熟悉該項工作。 (7) 對每一個關鍵的技術人員都指定一個后備人員。第18章 軟件工程風險管理 隨著項目的進展，開始進行風險監(jiān)控活動。項目管理者監(jiān)控某些因素，這些因素可以提供風險是否正在變高或變低的指示。針對人員頻繁流動的風險，應當監(jiān)控下列因素：(1) 項

15、目組成員對于項目壓力的一般態(tài)度。(2) 項目組的凝聚力。(3) 項目組成員彼此之間的關系。(4) 與報酬和利益相關的潛在問題。(5) 在公司內和公司外工作的可能性。第18章 軟件工程風險管理 除了監(jiān)控上述因素之外，項目管理者還應當監(jiān)控預設的風險緩解步驟的效力。例如，前述的一個風險緩解步驟中要求定義“定義文檔的標準，并建立保證文檔能夠被及時、正確建立的機制”。 如果有關鍵的人員離開了項目組，這就是一個保持工作連續(xù)性的機制。項目管理者應當仔細監(jiān)控這些文檔，以保證每一個文檔內容正確，而且當新員工加入項目組時，能夠利用已經建立并得到監(jiān)控的文檔為他們提供必要的信息。 第18章 軟件工程風險管理 如果風險

16、緩解工作失敗，風險已經發(fā)生，那么就要按照風險管理和意外事件處理計劃(風險應對預案)進行處理，減少風險帶來的損失。假定項目進行過程中，有一些人宣布要離開，如果我們執(zhí)行了緩解措施，那么就有后備人員可用，同時因為信息已經文檔化，并且有關知識已經在項目組中廣泛地進行了交流，后備人員能夠很快地接手工作。此外，項目管理者還可以暫時重新將資源調整到那些人員充足的功能上去(并對項目進度作必要的調整)，從而使得新加入的人員能夠“趕上進度”。 同時，應當要求宣布要離開的人員停止工作，在最后一段時間里進入“知識與業(yè)務交接”模式。第18章 軟件工程風險管理 應當注意的是，在防范風險的過程中是要花費成本的。應當在防范措

17、施的成本和風險一旦發(fā)生的損失之間進行投入產出分析，以此確定要執(zhí)行什么樣的風險防范措施。舉例來說，為每個項目組成員都配備一名后備人員就沒有必要。 在風險緩解和風險監(jiān)控措施中，應當注意抓主要風險。經驗證明，整個軟件風險的80%，可以由僅僅20% 的已標識出的風險來說明。在早期進行風險排序，能夠幫助項目管理者識別出這20% 的主要風險。其他一些已標識出的風險雖然已經評估、預測過，但可以不納入RMMM計劃之中。第18章 軟件工程風險管理 18.5 RMMM 計計 劃劃 風險管理策略可以包含在軟件項目開發(fā)計劃中，也可以建立一個獨立的風險緩解、監(jiān)控和管理計劃(RMMM計劃)。RMMM計劃將所有的風險分析工

18、作文檔化，并作為整個項目計劃中的一部分來使用。RMMM計劃的大綱如下：1. 引言1.1 文檔的范圍和目的1.2 主要風險綜述1.3 責任劃分A. 管理者B. 技術人員第18章 軟件工程風險管理 2. 項目風險表2.1 中止線以上的所有風險的描述2.2 影響概率及影響的因素3. 風險緩解、監(jiān)控和管理3.1 風險1緩解第18章 軟件工程風險管理 3.n 風險nA. 緩解. 一般策略. 緩解風險的特定步驟B. 監(jiān)控. 被監(jiān)控的因素. 監(jiān)控方法C. 管理. 意外事件計劃. 特殊考慮4. RMMM計劃的迭代時間安排表5. 總結第18章 軟件工程風險管理 一旦建立了RMMM計劃且項目已經啟動，則風險緩解及監(jiān)控活動也就隨之開始。正如前面討論過的，風險緩解是一種“問題避免”活動；風險監(jiān)控則是一種項目跟蹤活動，它包括三個主要目的：評估一個被預測的風險是否真正發(fā)生了；保證為風險而定義的緩解步驟被正確地實施；收集能夠用于今后的風險分析的信息。在很多情況下，項目中發(fā)生的問題可以追溯到不止一個風險，所以風險監(jiān)控的另一個任務就是試圖在整個項目中確定問題的“起源”(什么風險引起了什么問題)。第18章 軟件工程風險管理 18.6 小小 結結 當軟件項目成功的期