第5章-軟件項目風險管理

第五章軟件項目風險管理第一頁，共八十九頁。案例場景模擬(1/4)項目已成功實施1個月，某天項目組成員小謝突然告訴項目負責人，他已辦理好了去德國的簽證，2周后他會辭職離開公司前往德國留學

（人員）小謝的離開顯然將會影響項目組的正常運作，影響項目的進度，為此將會給項目的實施帶來損失可以想象，2周以后小謝的離開將會帶來一系列問題：誰來接替小謝的工作？在此之前誰來負責交接小謝的工作？如何盡可能的避免由此給項目組帶來的損失(包括進度損失和工作損失等)盡管還沒發(fā)生，但必須考慮如何避免問題的發(fā)生，以及一旦發(fā)生后該采取得措施，以便將損失減少到最少第二頁，共八十九頁。案例場景模擬(2/4)按照軟件開發(fā)計劃，需求分析應在12月31日前完成，然而在軟件項目實施過程中項目經(jīng)理發(fā)現(xiàn)，由于原先對工作量估算過于樂觀，需求分析在12月31日之前已經(jīng)不可能完成

（計劃）顯然，原先計劃制定的不科學和不準確，導致了實施過程中進度難以控制，如果強行按照計劃來執(zhí)行顯然是不可行的，為此，必須對計劃重新進行分析和調(diào)整第三頁，共八十九頁。案例場景模擬(3/4)在軟件設(shè)計階段，軟件設(shè)計負責人發(fā)現(xiàn)，用戶需求中的某項需求(例如，將已有word文檔的內(nèi)容顯示在Web頁面上)至今尚未找到解決的技術(shù)途徑

（技術(shù)）顯然，該問題將直接影響軟件項目的后續(xù)開發(fā)工作，影響到軟件項目能否成功完成第四頁，共八十九頁。案例場景模擬(4/4)在需求分析過程中，軟件設(shè)計負責人帶領(lǐng)的需求分析小組和用戶在進行交流的過程中發(fā)生了矛盾，出現(xiàn)了爭吵，用戶方說將不再配合需求分析小組的工作，而且他們確實沒有配合開發(fā)方的工作

（合作）顯然，開發(fā)方和用戶方出現(xiàn)這種狀況是雙方?jīng)]有想到的這種狀況延續(xù)下去必將對軟件項目的實施產(chǎn)生影響，影響軟件項目的進度，甚至會導致項目失敗第五頁，共八十九頁。案例啟示：風險在項目實施過程中大量存在軟件風險形式多樣軟件風險事先難以確定軟件風險會對軟件項目的實施產(chǎn)生不良影響如果不對風險進行良好的管理，項目就很難保證按照計劃、在成本和進度范圍內(nèi)，開發(fā)出高質(zhì)量的軟件產(chǎn)品，甚至會導致項目失敗第六頁，共八十九頁。5.1概述5.1.1風險5.1.2軟件風險5.1.3軟件項目風險管理5.1.4軟件項目風險管理的意義第七頁，共八十九頁。5.1.1風險卡內(nèi)基.梅隆大學的軟件工程研究所SEI：

風險是損失的可能性Webster’sDictionary：

風險是遭受損失、傷害、破壞的可能性。風險的根源是不利的情況(或損失)發(fā)生的不確定性，即不期望發(fā)生事件的客觀不確定性。風險是在給定情況下和特定時間內(nèi)，那些可能發(fā)生的結(jié)果之間的差異，差異越大則風險越大。第八頁，共八十九頁。5.1.1風險風險具有兩大屬性：可能性：風險發(fā)生的概率損失：指預期與后果之間的差異風險的損失=可能性×損失第九頁，共八十九頁。項目風險函數(shù)表達式項目風險具有不同的組成要素，如項目不希望發(fā)生的事件、事件發(fā)生的概率、事件的后果等。每個項目的風險可定義為不確定性和后果的函數(shù)：風險=f（事件，不確定性，后果)風險=f(事故，安全措施)第十頁，共八十九頁。5.1.2軟件風險什么是軟件風險？使軟件項目的實施受到影響和損失、甚至導致失敗的、可能會發(fā)生的事件例如，人員的臨時流失，計劃過于樂觀，設(shè)計的低劣軟件風險的特點事先難以確定帶來損失，影響項目實施，甚至會導致項目失敗第十一頁，共八十九頁。5.1.2軟件風險軟件風險由管理過程風險和技術(shù)過程風險組成，又可分為：1、軟件項目風險2、軟件過程風險3、軟件產(chǎn)品風險第十二頁，共八十九頁。5.1.3軟件風險管理什么是軟件風險管理？軟件風險管理與項目管理的關(guān)系軟件風險管理的主要內(nèi)容第十三頁，共八十九頁。什么是軟件風險管理？(1/3)面對軟件風險，一般有兩類方法：被動救火型主動防火型軟件風險管理屬于主動防火型方法第十四頁，共八十九頁。什么是軟件風險管理？(2/3)軟件風險管理是對影響軟件項目、過程或產(chǎn)品的風險進行估計和控制的實踐過程。定義目標。從目標逆向思維可發(fā)現(xiàn)軟件風險。根據(jù)不確定性、損失和時間來描述風險。第十五頁，共八十九頁。風險管理的涵義根據(jù)美國項目管理學會（PMI）的報告，風險管理有三個涵義：系統(tǒng)識別和評估風險因素的形式化過程。識別和控制能夠引起不希望的變化的潛在領(lǐng)域和事件的形式、系統(tǒng)的方法。在項目期間識別、分析風險因素，采取必要對策的決策科學和決策藝術(shù)的結(jié)合。第十六頁，共八十九頁。什么是軟件風險管理？(3/3)在風險影響軟件項目成功實施前，對它進行識別和處理，并預防和消除風險的發(fā)生。識別風險(會有哪些風險？)預防和消除風險(最好別讓風險發(fā)生)制定風險發(fā)生后的處理措施(萬一發(fā)生該怎么辦？)第十七頁，共八十九頁。軟件風險管理未來是我們所關(guān)心的——什么樣的風險會導致軟件項目徹底失敗呢？改變也是我們所關(guān)心的——用戶需求、開發(fā)技術(shù)、目標計算機、以及所有其他與項目相關(guān)的因素的改變將會對按時交付和總體成功產(chǎn)生什么影響呢？最后，我們必須抓住機會——我們應該采用什么方法及工具？需要多少人員參與工作？對質(zhì)量的要求要達到什么程度才是“足夠的”？第十八頁，共八十九頁。軟件風險管理過程風險管理過程就是從一堆模糊不清的問題、擔心和未知開始，逐步將這些不確定因素加以辨識、分析，并進而轉(zhuǎn)化為可接受的風險。

風險管理過程是一個持續(xù)不斷的過程，貫穿于項目周期的始終。第十九頁，共八十九頁。軟件風險管理與項目管理的關(guān)系軟件風險管理是整個項目管理的一部分。風險管理與項目管理的關(guān)系可歸納如下：從項目的成本、時間和質(zhì)量目標來看，風險管理與項目管理的目標一致。從項目管理的計劃職能來看，風險管理為項目計劃的制定提供了依據(jù)。從項目的成本管理職能來看，項目風險管理通過風險分析，指出有哪些可能的計劃外費用，并估計它的多少。從項目實施過程來看，許多風險都在項目實施過程中由潛在變?yōu)楝F(xiàn)實。定出風險反應計劃。第二十頁，共八十九頁。軟件風險管理的主要內(nèi)容第二十一頁，共八十九頁。項目風險管理內(nèi)容RiskManagementPlanning－風險管理計劃RiskIdentification－風險識別QualitativeRiskAnalysis－風險定性分析QuantitativeRiskAnalysis－風險定量分析RiskResponsePlanning－風險應對計劃Riskmonitoringandcontrol－風險監(jiān)控第二十二頁，共八十九頁。5.1.4軟件項目風險管理的意義KPMG即畢馬威，著名的"BIGFOUR"——國際四大會計師事務(wù)所之一（其他三大事務(wù)所為PwC普華永道，DTT德勤和E&Y安永）的一項調(diào)查指出55%失控的項目是沒有進行了風險管理；38%的失控項目作了一些,但是其中的一半在項目進行后就沒有使用風險監(jiān)督；剩余7%情況不明。項目實施風險管理的意義，見P141的8點第二十三頁，共八十九頁。5.2風險識別第二十四頁，共八十九頁。5.2風險識別風險識別，或稱風險辨識，是尋找可能影響項目的風險以及確認風險特性的過程。風險識別活動的參加人員一般包括：項目組成員、風險管理人員、學科專家（組織內(nèi)）、客戶、項目的其他管理人員以及外部專家等。風險識別的目標是：辨識項目面臨的風險，揭示風險和風險來源，以文檔及數(shù)據(jù)庫的形式記錄風險。第二十五頁，共八十九頁。5.2.1風險識別依據(jù)項目計劃歷史與經(jīng)驗信息外部制度約束風險項目內(nèi)部的不確定性第二十六頁，共八十九頁。5.2.2常見軟件風險風險的類別計劃編制組織和管理開發(fā)環(huán)境最終用戶客戶承包商需求產(chǎn)品外部環(huán)境人員設(shè)計和實現(xiàn)過程第二十七頁，共八十九頁。政府客戶供貨商分包商潛在的客戶最終用戶項目經(jīng)理團隊發(fā)起人競爭者組織集中管理同事其他的項目自然環(huán)境人員時間資金技術(shù)其他要素項目風險來源第二十八頁，共八十九頁。計劃編制風險計劃、資源和產(chǎn)品的定義完全由客戶或上層領(lǐng)導決定，忽略了項目組的意見，并且這些決定不完全一致計劃忽略了必要的任務(wù)和活動計劃不切實際計劃基于特定小組成員，而這樣的小組成員根本得不到產(chǎn)品規(guī)模估算過于樂觀工作量估算過于樂觀進度的壓力造成生產(chǎn)率的下降目標日期提前，但沒有相應地調(diào)整產(chǎn)品范圍和可用資源一個關(guān)鍵任務(wù)的延遲導致其他相關(guān)任務(wù)的連鎖反應……第二十九頁，共八十九頁。組織和管理風險缺乏強有力、有凝聚力的領(lǐng)導(項目組、企業(yè))解雇員工導致項目小組能力下降削減預算打亂項目計劃僅由管理層和市場人員進行技術(shù)決策，導致進度延長低效的項目組組織結(jié)構(gòu)降低生產(chǎn)率管理層審查/決策的周期比預期時間長管理層作出了打擊項目組積極性的決定非技術(shù)的第三方的工作比預期要長(如,采購硬件設(shè)備)計劃性太差，無法適應期望的開發(fā)速度項目計劃由于壓力而放棄，導致開發(fā)混亂管理方面的英雄主義，忽視客觀確切的狀態(tài)報告，降低發(fā)現(xiàn)和改正問題的能力第三十頁，共八十九頁。開發(fā)環(huán)境風險設(shè)施不能及時到位設(shè)施到位，但不配套開發(fā)工具未能及時到位開發(fā)工具不如期望的那樣有效，開發(fā)人員需要更多的時間，或者更換工具開發(fā)工具的學習期比預期的要長開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的功能第三十一頁，共八十九頁。最終用戶風險最終用戶堅持新的需求最終用戶對最后交付的產(chǎn)品不滿意，要求重新設(shè)計和重做最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持最終用戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶要求第三十二頁，共八十九頁。組織和管理風險缺乏強有力、有凝聚力的領(lǐng)導(項目組、企業(yè))解雇員工導致項目小組能力下降削減預算打亂項目計劃僅由管理層和市場人員進行技術(shù)決策，導致進度延長低效的項目組組織結(jié)構(gòu)降低生產(chǎn)率管理層審查/決策的周期比預期時間長管理層作出了打擊項目組積極性的決定非技術(shù)的第三方的工作比預期要長(如,采購硬件設(shè)備)計劃性太差，無法適應期望的開發(fā)速度項目計劃由于壓力而放棄，導致開發(fā)混亂管理方面的英雄主義，忽視客觀確切的狀態(tài)報告，降低發(fā)現(xiàn)和改正問題的能力第三十三頁，共八十九頁。開發(fā)環(huán)境風險設(shè)施不能及時到位設(shè)施到位，但不配套開發(fā)工具未能及時到位開發(fā)工具不如期望的那樣有效，開發(fā)人員需要更多的時間，或者更換工具開發(fā)工具的學習期比預期的要長開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的功能第三十四頁，共八十九頁。最終用戶風險最終用戶堅持新的需求最終用戶對最后交付的產(chǎn)品不滿意，要求重新設(shè)計和重做最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持最終用戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶要求第三十五頁，共八十九頁?？蛻麸L險(1/2)客戶堅持新的需求客戶對規(guī)劃、原型和規(guī)格的審核/決策超出預期客戶沒有參與規(guī)劃、原型和規(guī)格的審核，導致需求不穩(wěn)定，以及長時間的變更客戶答復的時間比預期的要長客戶堅持技術(shù)決策而導致計劃延長客戶對開發(fā)進度管理過細，導致實際進度變慢客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導致需要額外的設(shè)計和集成工作客戶提供的組件質(zhì)量欠佳，導致額外的測試、設(shè)計或者功能不完善第三十六頁，共八十九頁?？蛻麸L險(2/2)客戶要求的支持工具與環(huán)境不兼容，性能差或者不完善，導致生產(chǎn)率降低客戶不接受交付的軟件，盡管它滿足了所有的規(guī)格客戶期望的開發(fā)速度是開發(fā)人員所無法達到的第三十七頁，共八十九頁。承包商風險承包商沒有按照承諾交付產(chǎn)品承包商提供的產(chǎn)品質(zhì)量低下，必須花時間改進質(zhì)量承包商提供的產(chǎn)品性能達不到要求第三十八頁，共八十九頁。需求風險需求已經(jīng)成為項目基準，但仍在變化需求定義欠佳：不清晰、不準確、不一致增加額外的需求第三十九頁，共八十九頁。產(chǎn)品風險錯誤發(fā)生率高的模塊，需要更多的時間對它進行測試、設(shè)計和實現(xiàn)矯正質(zhì)量低下的不可接受的產(chǎn)品需要更多的時間對它進行測試、設(shè)計和實現(xiàn)由于功能錯誤，導致需要重新進行設(shè)計和實現(xiàn)開發(fā)額外不需要的功能延長了進度要滿足產(chǎn)品規(guī)模和速度要求，需要更多的時間嚴格要求與現(xiàn)有系統(tǒng)兼容，需要更多的時間要求軟件重用，需要更多的時間……第四十頁，共八十九頁。外部環(huán)境風險產(chǎn)品依賴政府規(guī)章，而規(guī)章的改變不可預期產(chǎn)品依賴草擬中的技術(shù)標準，而最后的標準不可預期第四十一頁，共八十九頁。人員風險(1/3)招聘人員所需的時間比預期要長作為人員參與工作的先決條件(如培訓、其他項目的完成等)不能按時完成開發(fā)人員與管理層關(guān)系不佳導致決策遲緩、影響全局項目組成員沒有全身心地投入到項目中，因而無法達到所需的產(chǎn)品功能和性能需求缺乏激勵措施、士氣低下，降低生產(chǎn)能力缺乏必要的規(guī)范，增加工作失誤，重復工作，降低工作質(zhì)量缺乏工作基礎(chǔ)(語言、經(jīng)驗、工具等)項目結(jié)束前，項目組成員離開項目組第四十二頁，共八十九頁。人員風險(2/3)項目后期，加入新的開發(fā)人員，額外的培訓和溝通降低了項目組成員的開發(fā)效率項目組成員不能有效的在一起工作由于項目組成員之間的沖突，導致溝通不暢，設(shè)計欠佳，接口錯誤和額外重復的工作有問題的項目組成員沒有調(diào)離項目組，影響其他成員的積極性項目組的最佳人選沒有加入項目組，或者加入項目組但沒有合理使用關(guān)鍵任務(wù)只能兼職參與項目人員不足第四十三頁，共八十九頁。人員風險(3/3)任務(wù)的分配和人員的技能不匹配人員工作的進展比預期的要慢項目管理人員怠工導致計劃和進度失效技術(shù)人員怠工導致工作遺漏、質(zhì)量低下，工作需要重做第四十四頁，共八十九頁。設(shè)計和實現(xiàn)風險設(shè)計過于簡單，考慮不仔細、不全面，導致重新設(shè)計和實現(xiàn)設(shè)計過于復雜，導致一些不必要的工作，影響效率設(shè)計質(zhì)量低下，導致重新設(shè)計和實現(xiàn)使用不熟悉的方法，導致需要額外的培訓時間產(chǎn)品使用低級語言編寫，導致效率較低分別開發(fā)的模塊無法有效集成，需要重新設(shè)計和實現(xiàn)第四十五頁，共八十九頁。過程風險跟蹤不準確，導致無法預知項目進展是否落后于計劃前期的質(zhì)量保證行為不真實，導致后期的重復工作質(zhì)量跟蹤不準確，導致無法得知影響進度的質(zhì)量問題不能有效遵循標準，導致溝通不足，質(zhì)量問題和重復工作風險管理粗心，導致沒有發(fā)現(xiàn)重大的項目風險……第四十六頁，共八十九頁。例子:風險列表第四十七頁，共八十九頁。各階段典型風險事件48啟動階段計劃階段執(zhí)行階段收尾階段缺少相應專業(yè)的專家對需求界定不清沒有做可行性研究目標不清沒有風險管理計劃倉促計劃缺少管理層支持職能界定差項目隊伍缺乏經(jīng)驗人員技能不夠材料短缺人員誤工天氣影響范圍改變項目進度改變環(huán)境要求沒有適當?shù)目刂企w系產(chǎn)品或服務(wù)質(zhì)量差客戶不能接受成果現(xiàn)金流出現(xiàn)問題風險發(fā)生最高時期風險影響最高時期機會和風險得失量時間各階段典型的風險事件風險價值第四十八頁，共八十九頁。5.2.3風險識別過程風險分析過程是將項目的不確定性轉(zhuǎn)變?yōu)轱L險陳述的過程。它包括以下活動：進行風險評估系統(tǒng)地識別風險風險定義及分類確定風險驅(qū)動因素將風險編寫為文檔P144第四十九頁，共八十九頁。5.2.4風險識別方法與技術(shù)有很多有效的方法，主要有：核對清單頭腦風暴法Delphi法會議法匿名風險報告機制…第五十頁，共八十九頁。1.核對清單可以采用SEI推薦的軟件風險分類系統(tǒng)或項目工作細分結(jié)構(gòu)WBS作為核對清單。SEI軟件風險分類系統(tǒng)是一個結(jié)構(gòu)化的核對清單。SEI軟件風險分類系統(tǒng)將風險分為產(chǎn)品工程、開發(fā)環(huán)境和項目約束三類。每類又分若干元素，每個元素通過其屬性來體現(xiàn)特征。SEI軟件風險分類系統(tǒng)如P145表5.1所示:第五十一頁，共八十九頁。第五十二頁，共八十九頁。WBS模型項目工作細分結(jié)構(gòu)WBS提供了識別具體項目風險的框架。每一個項目元素都以支持項目開發(fā)活動（計劃、執(zhí)行、控制等）的細節(jié)方式被定義。WBS減少了項目的灰度，使項目結(jié)構(gòu)清晰。第五十三頁，共八十九頁。WBS模型第五十四頁，共八十九頁。2.頭腦風暴法召集項目組全體會議，進行關(guān)于項目風險的自由討論，項目組成員在主持人的引導下完全自由地發(fā)言，不受限制，產(chǎn)生關(guān)于項目風險的概念。頭腦風暴法是一種搜集項目風險的常用方法。第五十五頁，共八十九頁。3.Delphi法Delphi法又稱反饋匿名函詢法，本質(zhì)上是一種達到關(guān)于一個科目的專家一致意見的方法。這個“科目”可以是軟件成本，軟件項目風險等。任命專家→專家匿名參加→發(fā)調(diào)查表給專家→專家填寫→由調(diào)查人員將專家意見匯總整理→再返回起點。這個方法體現(xiàn)了民主性。第五十六頁，共八十九頁。4.會議法定期的項目組會議，如項目轉(zhuǎn)折點或重要變更時舉行的會議、項目月及季度總結(jié)會項目專家會議都適宜于談?wù)擄L險信息，將風險討論列為會議議題。第五十七頁，共八十九頁。5.SWOT分析法SWOT技術(shù)（Strengths,Weankness,Opportunities,Threats)是分析項目內(nèi)部優(yōu)勢與弱勢和項目外部機會與威脅綜合分析的代名詞。主要對項目的優(yōu)勢和劣勢、機會與威脅等各方面，從多角度對項目風險進行識別。第五十八頁，共八十九頁。SWOT分析法內(nèi)部因素外部因素SWOT第五十九頁，共八十九頁。示例積極消極內(nèi)部外部第六十頁，共八十九頁。6.匿名風險報告機制向管理層或組內(nèi)報告好的消息很少會出現(xiàn)問題，但報告項目的壞消息則不然。必須有一個匿名的風險交流渠道。第六十一頁，共八十九頁。5.3風險分析第六十二頁，共八十九頁。5.3風險分析風險分析是人們應用風險分析工具,加深對風險的認識與理解，使風險及風險背景明晰化，從而為有效地管理風險提供基礎(chǔ)。風險分析活動的過程目標包括：提煉風險背景，確定風險來源，確定行動時間框架，確定前10項首要風險名單等。第六十三頁，共八十九頁。5.3.1風險分析過程定義風險度量準則預測風險景響評估風險風險排序制訂風險計劃第六十四頁，共八十九頁。5.3.1風險分析過程---1.定義風險度量準則定義風險度量準則風險度量準則是按照重要性對風險進行排序的最基本依據(jù)。風險度量準則包括可能性、后果和行動時間框架。第六十五頁，共八十九頁。5.3.1風險分析過程----1.定義風險度量準則（1）可能性定性度量包括：極低、低、中、高、極高，也可簡單定義為：低、中、高。（2）后果后果反映了風險對項目目標的影響程度。（3）行動時間框架行動時間框架是指采取有效措施規(guī)避風險的時限。第六十六頁，共八十九頁。5.3.1風險分析過程----2.預測風險影響我們用風險發(fā)生的可能性與風險后果的乘積來度量風險的影響。

風險影響（RE）=風險發(fā)生的可能性（P）*風險后果（C）可能性被定義為大于0，小于1。后果從1到10表示風險對成本、進度和技術(shù)目標的影響。兩者的乘積可能是經(jīng)濟的損失，也可能是時間的損失等。第六十七頁，共八十九頁。5.3.1風險分析過程---3.評估風險風險影響和行動時間框架決定了風險的相對嚴重程度，見P148表5.4。風險嚴重程度有利于區(qū)分當前風險的優(yōu)先級別。隨著時間的推移，風險嚴重程度發(fā)生變化，有利于提供當前項目面臨的重點問題。第六十八頁，共八十九頁。5.3.1風險分析過程----4.風險排序依據(jù)評估準確風險排序，可保證高風險影響和短行動時間框架的風險能被最先處理。右表是一個非常生要的風險報告形式，在實際項目中可以使用。第六十九頁，共八十九頁。5.3.1風險分析過程----5.制定風險計劃風險計劃是實施風險應對措施的依據(jù)與前提。風險計劃要包括：確定風險設(shè)想選擇風險應對途徑其中，常用作選擇風險應對途徑的取舍標準是風險倍率和風險多樣化。風險多樣化通過分散風險來減少風險。項目不要過分依賴一種方法、一種工具、一個人或一個廠商等。設(shè)定風險閾值編寫風險計劃第七十頁，共八十九頁。風險倍率風險倍率是一條風險應對法則，它通過減少風險影響來減少風險。風險應對成本是實施風險行動計劃的成本。倍率的概仿有助于確定獲得最高回報的行動。主要的風險倍率多存在于軟件生命周期的早期。第七十一頁，共八十九頁。5.3.2風險分析技巧與工具因果關(guān)系分析法決策分析法：用于構(gòu)建決策，用決策模型來代表真實世界里的問題。決策模型的元素包括決策、不確定事件以及結(jié)果的價值。差距分析法確定變量的差距。描述了人們意識到的重要性和實際執(zhí)行情況的差距，從而確定風險管理實踐是否需要改進。Pareto帕雷托分析法只要找出項目風險的20%關(guān)鍵致因，就可以解決項目的大部分問題敏感度分析法通過改變每一個輸入變量，保持其它變量，來確定厝型對輸入變量的敏感度。第七十二頁，共八十九頁。因果關(guān)系分析法—魚骨圖第七十三頁，共八十九頁。5.3.3風險分析的成果經(jīng)過風險分析，可以得到一個按優(yōu)先等級排序的風險列表。第七十四頁，共八十九頁。5.4風險跟蹤與應對第七十五頁，共八十九頁。風險控制風險管理計劃風險化解風險監(jiān)控第七十六頁，共八十九頁。風險監(jiān)控(1/2)檢查風險的化解程度及其變化(概率、損失)風險監(jiān)控的方式監(jiān)控和跟蹤重要的(前10個)風險，記錄風險危險度的變化以及風險化解的進展中間審查，在每個里程碑后進行小規(guī)模的走查任命風險官員(適合于大項目)，警告項目風險，防止項目經(jīng)理和開發(fā)人員忽略計劃中的風險管理第七十七頁，共八十九頁。風險管理計劃(2/2)例子，小謝將在項目實施過程中離開公司**項目組的小謝項目組成員小謝由于出國離開公司小謝可能會在6月1日前后出國為了進一步學習和深造和小謝協(xié)商能否在項目結(jié)束之后(大約7月中旬)離開如果離開，計劃讓小王接替他的工作，同時讓小劉分擔小王的一部分工作第七十八頁，共八十九頁。應對風險的基本措施規(guī)避。通過變更項目計劃消除風險或風險的觸發(fā)條件，使目標免受影響。轉(zhuǎn)移。不能消除風險，而是將項目風險的結(jié)果連同應對的權(quán)利轉(zhuǎn)移給第三方。弱化。將風險時間的概率或結(jié)果降低到一個可以接受的程度，其中降低發(fā)生的概率更為有效。接受。不改變項目計劃，而考慮發(fā)生后如何應對第七十九頁，共八十九頁。風險應對模擬場景風險化解方式避免風險：推遲小謝的離開時間將風險從系統(tǒng)的一部分轉(zhuǎn)移到另一部分：讓客戶來做消除發(fā)生風險的根源：加薪發(fā)布風險：不會突然和驚訝接受和控制風險：接受并提供處理計劃，安排小