【正文】 率是虧本的回報out∞mc〓度量100000，這樣項目成功的EMv〓（550000Ⅹ30％度量100000Ⅹ70％）70％〓66500，項目（30％概率）失敗的EMv〓度量60000，則實施后的EMv〓66500度量60000＝6500，而不實施此頊計劃的EMv〓0。圖中的曲線顯示了完成項目的累計可能牲與某一時間點的關系。圖10—9是根據(jù)多個項目的實際數(shù)據(jù)得出對這個三層結構檢查表的量化風險分析結果：其中ProductEnginOering占30％的風險，Dcvclopmt Environment占33％的風險，Program Constraints占37％的風險。規(guī)劃降低風險的主要策略是回避風險、轉(zhuǎn)移風險、損失控制以及自留風險。2）當其他的風險策略不理想的時候，才可以考慮這個策略。采購行為往往將一種風險置換為另一種風險。轉(zhuǎn)移風險有時也稱通過采購轉(zhuǎn)移風險，即從本項目組織外采購產(chǎn)品和服務，它常常是針對某些種類風險的有效對策。項目管理組不可能排除所有風險，但特定的風險事件往往是可以排除的。 概忿風險規(guī)劃是針對風險分析的結果，為提高實現(xiàn)項目目標的機會并降低風險的負面影響而制定風險應對策略和應對措施的過程，即通過制定一系列的行動和策略來對付、減少以至于消滅風險事件。應該從風險清單中選擇排序靠前的幾個風險（簡稱TOP10）作為風險評估的最終結果。大多模擬項目日程表是建立在某種形式的“蒙特卡羅”分析基礎上的。它用逐級逼近的計算方法；從出發(fā)點開始不斷產(chǎn)生分支以表示所分析問題的各種發(fā)展可能性，并以各分支的損益期望值中最大者（如求極小，則為最小者）作為選擇的依據(jù)。如果風險的組合所產(chǎn)生的問題超出了一個或多個參照水平值，就應該終止該項目的工作。如果風險損失后果的大小不容易直接估計出來，可以將損失分解為更小的部分，再對其進行評估，然后將各部分評估結果累加，形成一個合計評估值。 定量風險評估通過定性風險評估，人們能對項目風險有一個大致了解，可以了解項目的薄弱環(huán)節(jié)。數(shù)字等級的劃分具有隨意性，但要便于區(qū)別各種風險的檔次，劃分得過細或過粗都不便子風險的決策，因此需要根據(jù)具體對象制定。風險概率值是介于沒有可能（＞0）和確定（＜l）之間的。然后建立風險表，按風險的嚴重性排序，確定最需要關注的前幾個（TOP 10，一般說前10個，具體多少個可以視項目的具體情況而定）風險。每個Class組下包含若干Elemt（元素），每個Elemt組下又包含若干Attributc（屬性）。開發(fā)人員是否能夠自始至終地參加整個項目的工作？環(huán)境是否利用了數(shù)據(jù)庫或數(shù)據(jù)倉庫？下面的風險檢查表中的條目標識了與開發(fā)環(huán)境相關的風險：待開發(fā)的軟件是否需要與功能和性能均未在本領域得到證實的數(shù)據(jù)庫系統(tǒng)接口？是否收集所有軟件項目的質(zhì)量度量值？是否使用特定的方法進行數(shù)據(jù)和體系結構的設計？是否定期對測試過程和測試情況進行復審，高級管理層是否有一份已經(jīng)寫好的政策陳述，該陳述中強調(diào)了軟件開發(fā)標準過程的重要性？該客戶是否同意花時間召開正式的需求收集會議，以確定項目范圍？一些人會對質(zhì)量好的產(chǎn)品表示贊賞，而另一些人則不管怎樣都抱怨不休。對需求的變化缺少相關分析。沒有優(yōu)先需求。每一種情況都會使人不愉怏。最終用戶的水平如何？產(chǎn)品的用戶數(shù)有多少？人員數(shù)目及其經(jīng)驗其中每一方面包含很多的風險檢查條目，通過對每個條目的回答，可以識別項目可能存在的風險。一般說，作為項目經(jīng)理可以將主要的精力放在以下幾方面：當一個項目持續(xù)的時間較長時，往往要考慮各種技術、經(jīng)濟和社會因素的影響，對這種項目進行風險預測和識別，就可用情景分析法來預測和識別其關鍵風險因素及其影響程度。我們在進行成本估算的時候也用到這種方法。嚴格來說，風險僅僅指道受創(chuàng)傷和損失的可能性，但對項目而言，風險識別還窯涉機會選擇（積極成本）和不利因素威脅（消極結果）。每一類風險可以分為兩種不同的情況：一般性風險和特定性風險。主動策略早在技術工作開始之前就已經(jīng)啟動了：標識出潛在的風險，評估它們出現(xiàn)的概率及產(chǎn)生的影響，對風險按重要性進行排序，然后軟件項目組建立一個計劃來管理風險。這樣，項目經(jīng)理可以將精力更多地放到項目的及時提交上，不用像救火隊員一樣，處于被動狀態(tài)。1）從項目進度、質(zhì)量和成本目標看，項目管理與風險管理的目標是一致的。例如，一個高利潤高收益的公司也許愿意為一個10億美元的合同花費50萬美元制作一份計劃書，而亠個收支相抵的公司則不會。 風險的基本性質(zhì)風險具有如下的基本性質(zhì)：1）客觀性風險客觀性首先表現(xiàn)在它的存在是不以人的意志為轉(zhuǎn)移的，因為決定風險的各種因素對風險主體是獨立存在的，不管風險主體是否意識到風險的存在，在一定的條件下風險就可能變?yōu)楝F(xiàn)實。由于重點轉(zhuǎn)移或者人員變動而失去上級管理部門的支持，就發(fā)生了管理風險。規(guī)格說明的多義性、技術上的不確定性、技術陳舊也是技術風險因素。如圖10ˉ3所示，風險發(fā)生的概率越高，造成的影響越大，就越是高風險，否則就是中等風險或者低風險。一個項目的損失可能有不同的后果形式，例如軟件質(zhì)量的下降、成本費用的超出、項目進度的推遲等。另一方面，風險是一種概率事件——它可能發(fā)生也可能不發(fā)生。本章我們進人路線圖的第9站：風險計劃，如圖10—1所示。項目中的風險有很多種，沒有風險的項目幾乎是不存在的，只是風險的多少、嚴重程度不同而已。因此，風險管理被認為是管理大型軟件項目的最佳實踐。風險事件是指那些人們不愿意它發(fā)生的或者沒有規(guī)劃的事件。在我們能夠標識出軟件項目中的真正風險之前，識別出所有對管理耆和開發(fā)者而言均為明顯的風險是很重要的。例如：從預測角度看，風險可以分為下面三種類型：已知風險、可預測風險、不可預測風險。由于人們對客觀世界的認識受到各種條件的限制，不可能準確地預測風險的發(fā)生，不確定性要求我們運用各種方法進行測度。沒有利益只有風險，沒人會做；實現(xiàn)利益必須承擔一定的風險。3）從項目實施過程看，不少風險是在項目實施過程中由潛在變成現(xiàn)實的，風險管理就是在風險分析的基礎上擬定具體措施來消除、緩和及轉(zhuǎn)移風險，并避兔產(chǎn)生新的風險。正如Tom Gilb所說，“女口果你不主動攻擊風險，風險就會主動攻擊你”。消滅根源：識別和消滅可能產(chǎn)生風險的根源。軟件風險管理要求在風險成為影響項目成功的因素之前識別、著手處理卉消除風險的源頭，所有的項目都有風險，如果忽視風險，就可能增加項目失敗的可能性，或者導致項目不成功。為了識別特定性風險，必須檢查項目計劃及軟件范圍說明，從而了解本項目中有什么特性可能會威脅到項目計劃。 概念風險識別過程見圖104，其中，風險識別的輸入可能是項目的WBS、SOW、項目相關信息、項目計劃假設、歷史項目數(shù)據(jù)，其他項目經(jīng)驗文件、評審報告、公司目標等。 頭腦風暴法所謂頭腦風暴法，就是以專家的創(chuàng)造性思維來獲取未來信，a的一種直觀預測和識別方法。 風險條目檢查表“風險條目檢查表”是最常用也是比較簡單的風險識別方法，它是利用一組提問來幫助管理者了解項目在各個方面有哪些風險。項目需求是否以LOC或FP估算產(chǎn)品的規(guī)模？本產(chǎn)品對公司的收人有何影響？產(chǎn)品缺陷所造成的成本消耗是多少？對于上述產(chǎn)品規(guī)模和商業(yè)影響的風險檢查表中的每一個回答都必須與過去∞經(jīng)驗加以比較。有些人只知道他們需要什么，而有些人知道他們不需要什么。一個“不好的”客戶可能會對一個軟件項目組能否在預算內(nèi)完成項目產(chǎn)生很大的影響。該客戶是否具有該產(chǎn)品領域的技術奏養(yǎng)？該軟件過程是否可以用子其他項目？是否使用配置管理來維護系統(tǒng)／軟件需求、設計、編碼、測試用例之間的一致性？是否使用特定的方法進行測試用例的設計？下面的風險檢查表中的條目標識了與建造的技術相關的常見風險：需求中是否要求采用新的分析、設計、測試方法？ ⒒是否有可用的分析及設計工具？工具的聯(lián)機幫助及文檔是否適當？如果對于上述問題的答案多數(shù)是否定的，則軟件開發(fā)環(huán)境是薄弱的且風險很高。開發(fā)人員是否接受過必要的培訓？圖10度量5風險三層分析結構表亻0丬 三層風險檢查表類（Class）元素（ElCmt）屬性（Attributc）產(chǎn)品工程（Product Enginccring）需求（RCquiremts）穩(wěn)定性〈Stability）完整性（Co