1、1,第二講 風險辨識,風險辨識的階段； 風險辨識的前提條件； 風險辨識的內容； 風險辨識的原則； 風險辨識的過程； 風險辨識的基本方法。,2,第二講 風險辨識,一、風險辨識的階段 1.感知風險 即通過調查和了解,辨識風險的存在。 2.分析風險 即通過歸類分析,掌握風險產生的原因和條件,以及風險所具有的性質。 感知風險是風險辨識的基礎，分析風險是風險辨識的關鍵。,3,4,第二講 風險辨識,二、風險辨識的前提因素 1.風險主體的風險意識 風險辨識是一項復雜的系統(tǒng)工程； 合理選擇風險辨識方法； 風險辨識是一個連續(xù)不斷的過程。,5,第二講 風險辨識,2.風險主體的活動 風險主體活動的性質； 風險主體的

2、生產經營方式； 風險主體的生產經營過程。,6,第二講 風險辨識,3.風險主體的經營環(huán)境 風險主體的生產經營活動總是處在一定的環(huán)境中的，這些環(huán)境包括政治、經濟、自然、法律及各種物質環(huán)境。掌握環(huán)境狀況，便于辨識、分析風險。,7,第二講 風險辨識,8,第二講 風險辨識,三、風險辨識的內容 風險是什么？ 風險因素是什么？ 導致風險事故的主要原因和條件是什么？ 風險事故的后果是什么？ 風險辨識的方法是什么？ 如何進行風險管理？,9,第二講 風險辨識,四、風險辨識的原則 由粗及細，由細及粗； 先懷疑，后排除； 必要時做實驗確認。,10,第二講 風險辨識,五、風險辨識的過程,確認不確定性的客觀存在,建立初步

3、清單,確定各種風險事件并推測結果,制訂風險預測圖,進行風險分類,建立風險目錄摘要,11,第二講 風險辨識,例：工程承包風險分類表,12,第二講 風險辨識,六、風險辨識的基本方法,1.風險因素預先分析法（PHA） 調查系統(tǒng)出現(xiàn)事故的可能類型； 調查風險源； 辨識風險轉化條件；,風險源,危險狀態(tài),風險事故,損失,劃分等級。,轉化 條件,觸發(fā) 條件,13,第二講 風險辨識,2.事件樹分析法（ETA） 任何一個事故的發(fā)生，必定是一系列事件按時間順序相繼出現(xiàn)的結果，前一事件的出現(xiàn)是隨后事件發(fā)生的條件，在事件的發(fā)展過程中，每一事件有兩種可能的狀態(tài)，即成功和失敗。,14,第二講 風險辨識,行人過馬路,無車,

4、有車,車后通過,車前通過,有充足時間,無充足時間,駕駛員采取措施,駕駛員未采取措施,措施有效,措施無效,順利通過,順利通過,順利通過,順利通過,車禍,車禍,以行人過馬路為例來看事件樹分析的過程。,15,第二講 風險辨識,（3）保險調查法 指保險公司、有關咨詢機構、研究機構或學術團體的專業(yè)人員就風險主體可能遭遇的風險進行詳盡的調查與分析，并形成報告書，以供風險主體參考的一種方法。,16,第二講 風險辨識,（4）保單對照法 將保險公司現(xiàn)行出售的保單風險種類與風險分析調查表結合形成的用于風險辨識的問卷式表格。,（5）資產損失分析法 由美國管理學會設計的資產損失調查表供企業(yè)使用。此表配合風險分析調查表

5、使用。,17,第二講 風險辨識,（6）風險列舉法 站在消費者的立場，根據(jù)風險主體的作業(yè)流程和財務等相關資料分析并列舉每項活動可能遭遇的風險。也稱為邏輯分類法。,（7）實地檢視法 親自前往實地了解情況從而達到風險辨識的目的。全面了解造成損失的實際狀況并可以了解引起損失的危險事故和危險因素。,18,第二講 風險辨識,案例：軟件開發(fā)公司風險列表（風險列舉法） 1.客戶相關風險: 是否曾與這個客戶合作過； 客戶是否很清楚需要什么，能否花時間把需求寫出來； 客戶是否愿意建立與開發(fā)者的快速通信渠道； 客戶是否了解軟件過程； 客戶是否愿意參加復審工作； 該客戶是否具有該產品領域的技術實力； 該客戶是否愿意讓

6、你的人來做他們的工作，即當你的人在做具體的技術工作時，該客戶是否會堅持在旁邊協(xié)助 如果對這些問題中的任何一個的答案是否定的，則需要進行進一步分析，以評估潛在的風險。,19,第二講 風險辨識,2.商業(yè)影響風險 本產品是否得到公司高級管理層的重視； 交付期限合理性如何； 最終用戶的水平如何； 將使用本產品的用戶數(shù)及本產品是否與用戶的需要相符合； 必須產生并交付給用戶的產品文檔的質與量如何； 政府對本產品開發(fā)的約束； 延遲交付所造成的成本消耗是多少； 產品缺陷所造成的成本消耗是多少。 對每一個問題的回答都必須與過去的經驗加以比較，如出現(xiàn)了較大百分差或數(shù)字相近但過去的結果很不令人滿意，則風險較高。,2

7、0,第二講 風險辨識,3.產品規(guī)模風險 估算出來的產品規(guī)模的信任程度如何； 產品規(guī)模與以前產品的規(guī)模平均值的偏差百分比是多少； 產品創(chuàng)建或使用的數(shù)據(jù)庫大小如何； 產品的用戶數(shù)有多少； 產品需求改變多少，交付之前有多少，交付之后有多少； 復用的軟件有多少。,21,第二講 風險辨識,4.業(yè)務風險 如果競爭對手搶先將產品推向市場怎么辦； 如果項目資金處于危險境地怎么辦; 系統(tǒng)的預計價值是否大于預計成本？； 如果無法同關鍵的供應商簽定合同怎么辦。,22,第二講 風險辨識,5.過程風險 開發(fā)人員是否同意按照文檔所寫的軟件過程進行開發(fā)工作，并自愿使用它； 是否定期對需求規(guī)約、設計和編碼進行正式技術復審；

8、是否定期對測試過程和測試情況進行復審； 是否對每一次的正式技術復審的結果建立了文檔，其中包括發(fā)現(xiàn)的錯誤和使用的資源； 是否使用配置管理來維護系統(tǒng)/軟件需求、設計、編碼和測試用例之間的一致性； 開發(fā)時間延長（例如編碼時間延長）導致測試時間表規(guī)劃困難； 是否使用一個機制來控制用戶需求的變化及其對軟件的影響.,23,第二講 風險辨識,6.需求風險 對產品缺少清晰的認識； 對產品需求缺少認同； 在做需求中客戶參與不夠； 由于不確定的需要導致新的市場； 需求不斷變化； 對需求的變化缺少相關分析。,24,第二講 風險辨識,7.技術風險 該技術對于組織而言是否第一次使用； 客戶的需求是否需要創(chuàng)建新的算法或輸

9、入、輸出技術； 軟件是否需要使用新的或未經證實的硬件接口； 待開發(fā)的軟件是否需要與開發(fā)商提供的未經證實的軟件接口； 產品需求中是否要求采用特定的用戶界面； 待開發(fā)的軟件是否需要與其功能及性能均未在本領域中得到證實的數(shù)據(jù)庫接口； 需求中是否要求使用新的分析、設計、測試方法； 需求中是否有過分的對產品的性能約束；數(shù)據(jù)量是否合理； 客戶能確定所要求的功能是“可行的”。,25,第二講 風險辨識,8.人員風險 是否有最優(yōu)秀的人員可用； 人員在技術上是否配套； 是否有足夠的人員可用； 開發(fā)人員是否能夠自始至終的參加整個項目的工作； 開發(fā)人員對自己的工作是否有正確的期望； 開發(fā)人員是否接受過必要的培訓； 是否在一起工作過，合作性程度如何； 是否有領域專家?guī)椭?26,第二講 風險辨識,9.資金 完成項目所需的資金是否到位； 是否為培訓和指導分配了資金； 是否有預算限制使得系統(tǒng)必須以固定的成本交付； 成本估算是否準確。,27,第二講 風險辨識,10.外部依賴性風險 該項目是否依賴于其他（平行的）開發(fā)項目； 成功是否依賴于市售產品或外部開發(fā)的構件； 成功是否依賴于開發(fā)工具（設計工具、編譯器等）和實施技術（操作系統(tǒng)、數(shù)據(jù)庫、進程間通信機制等）的成功集成