1、卷號卷號 卷內(nèi)編號卷內(nèi)編號 密級密級 風險管理指南風險管理指南 Version 1.1 作者:技術(shù)委員會 分類: 使用者: 文檔編號： 托普信息 （iTOP）集團, 2002 文檔信息文檔信息 標題:風險管理指南 作者:SEPG 創(chuàng)建日期: 2002-4-23 上次更新日期: 版本:1.0 部門名稱: 修訂文檔歷史記錄修訂文檔歷史記錄 日期日期版本版本說明說明作者作者 2002-4-231.0創(chuàng)建孟勝 文檔信息文檔信息 標題:風險管理指南 作者:技術(shù)委員會 創(chuàng)建日期: 2002-4-23 上次更新日期: 版本:1.1 部門名稱: 托普信息（iTOP）集團 修訂文檔歷史記錄修訂文檔歷史記錄 日期

2、日期版本版本說明說明作者作者 2002-4-231.0創(chuàng)建孟勝 2002-8-291.1為了 iTOP 集團推廣 CMM 成果，對封面及部分 內(nèi)容作了調(diào)整 托普信息（iTOP）集 團技術(shù)委員會 目錄目錄 1.簡介簡介.1 1.1目的.1 1.2定義、首字母縮寫詞和縮略語.1 1.3參考資料.1 2.風險管理準備風險管理準備.1 2.1風險管理的組成.1 2.2風險種類.2 2.2.1資源風險.2 2.2.2業(yè)務風險.2 2.2.3技術(shù)風險.2 2.2.4進度風險.3 2.3定義風險參數(shù).3 2.4風險管理策略.4 2.5風險管理角色及職責.4 2.5.1項目經(jīng)理.4 2.5.2項目組開發(fā)人員.

3、4 2.5.3SQA.4 3.風險識別風險識別.4 4.風險分析風險分析.4 4.1發(fā)生的可能性.5 4.2影響的嚴重性.5 5.風險的優(yōu)先級風險的優(yōu)先級.5 6.風險的控制風險的控制.5 6.1控制方法.5 6.1.1風險管理計劃.5 6.1.2風險的化解.6 6.2風險監(jiān)控.6 6.2.1周例會檢查風險.6 6.2.2階段/迭代完成后重新評估風險.6 風險管理指南風險管理指南 1.簡介簡介 1.1目的目的 風險管理的目標是在潛在問題發(fā)作以前就標志它們，這樣就可以在生命周期中可以適時地計劃 和啟用風險處理活動。 1.2定義、首字母縮寫詞和縮略語定義、首字母縮寫詞和縮略語 PM Project

4、 Manager 1.3參考資料參考資料 RUP 快速軟件開發(fā) SW-CMM CMMI 2.風險管理準備風險管理準備 2.1風險管理的組成風險管理的組成 風險評估 風 險 識 別 風險控制 風險管理 風 險 分 析 風 險 優(yōu) 先 級 風 險 監(jiān) 控 風 險 化 解 風 險 管 理 計 劃 2.2風險種類風險種類 2.2.1資源風險 組織組織 對該項目是否有足夠的支持（包括管理人員、測試員、QA 和其他外部的相關(guān)各方）？ 這是否是該組織嘗試過的最大項目？ 軟件工程是否有明確定義的流程？需求記錄和管理？ 資金資金 完成項目所需的資金是否到位？ 是否為培訓和指導分配了資金？ 是否有預算限制使得系統(tǒng)

5、必須以固定的成本交付，否則將被取消？ 成本估算是否準確？ 人員人員 是否可以獲得足夠的人員？ 他們是否具備合適的技能和經(jīng)驗？ 他們以前是否在一起工作過？ 他們是否相信項目會成功？ 是否可以找到用戶代表來擔任復審員？ 是否可以找到領(lǐng)域?qū)＜遥?時間時間 時間表制定得是否現(xiàn)實？ 是否可以為了滿足時間表而對功能進行規(guī)模管理？ 對交付日期的要求有多嚴格？ 是否有時間“把工作做好”？ 2.2.2業(yè)務風險 如果競爭對手搶先將產(chǎn)品推向市場怎么辦？ 如果項目資金處于危險境地怎么辦（換句話說，“如何確保有足夠的資金”）？ 系統(tǒng)的預計價值是否大于預計成本？（務必要考慮貨幣的時間價值和資金的成本）。 如果無法同關(guān)鍵的

6、供應商簽定合同怎么辦？ 2.2.3技術(shù)風險 規(guī)模風險規(guī)模風險 成功是否能夠被評測？ 是否有關(guān)于如何評測成功的協(xié)議？ 需求是否相當穩(wěn)定并得到了充分的了解？ 項目規(guī)模是固定不變還是在不斷擴展？ 項目開發(fā)的時間范圍是否太短、不夠靈活？ 技術(shù)風險技術(shù)風險 技術(shù)是否已經(jīng)過證明？ 重復使用目標是否合理？ 工件必須要使用一次后才能被重復使用。 構(gòu)件可能要在若干次發(fā)布后才能變得穩(wěn)定，以致無需重大變更即可復用。 需求中的事務量是否合理？ 事務比率的估計值是否可靠？這些估計是否過于樂觀？ 數(shù)據(jù)量是否合理？當前可用的框架是否能夠保存這些數(shù)據(jù)，或者，如果需求使您相信 工作站或部門系統(tǒng)將成為設計的一部分，那么是否能夠在

7、這些地方合理地保存數(shù)據(jù)？ 是否有特殊或苛刻的技術(shù)需求（如要求項目團隊處理他們不熟悉的問題）？ 成功是否依賴于新的或未經(jīng)試驗的產(chǎn)品、服務或技術(shù)？是否依賴于新的或未被證明的 硬件、軟件或技術(shù)？ 對于與其他系統(tǒng)（包括企業(yè)以外的系統(tǒng)）的接口是否存在外部依賴性？是否存在必需 的接口或必須創(chuàng)建它們？ 是否存在極不靈活的可用性和安全性需求（例如“系統(tǒng)必須永遠不出現(xiàn)故障”）？ 系統(tǒng)的用戶是否對正在開發(fā)的系統(tǒng)類型沒有經(jīng)驗？ 應用程序的大小或復雜性，或者技術(shù)的新穎性是否導致了風險的增加？ 是否存在對國家語言支持的需求？ 是否可能設計、實施和運行該系統(tǒng)？某些系統(tǒng)只由于太大或太復雜而無法正常工作。 外部依賴性風險外部

8、依賴性風險 該項目是否依賴于其他（平行的）開發(fā)項目？ 成功是否依賴于市售產(chǎn)品或外部開發(fā)的構(gòu)件？ 成功是否依賴于開發(fā)工具（設計工具、編譯器等）和實施技術(shù)（操作系統(tǒng)、數(shù)據(jù)庫、 進程間通信機制等）的成功集成。您是否有替代計劃，可以在沒有這些技術(shù)的情況下 交付項目？ 2.2.4進度風險 功能是否無限追加 計劃是否過于樂觀； 是否缺乏計劃 在壓力下是否放棄計劃 是否追趕計劃 2.3定義風險參數(shù)定義風險參數(shù) 風險參數(shù)可用于評估、分類和劃分風險的優(yōu)先級； TP 集團將風險參數(shù)分為：“發(fā)生的可能性”和“影響的嚴重性”兩類 發(fā)生的可能性發(fā)生的可能性影響的嚴重性影響的嚴重性 名 稱等級名 稱等級 非?？赡馨l(fā)生3

9、非常嚴重4 可能發(fā)生2 嚴重3 不太可能發(fā)生1 中等2 輕微 1 2.4風險管理策略風險管理策略 有三種主要的策略： 風險規(guī)避風險規(guī)避：使其不再受到該風險的影響。 風險轉(zhuǎn)移：風險轉(zhuǎn)移：讓其他方（客戶、廠商、銀行、其他主體等）承擔該風險。 風險接受：風險接受：決定將該風險當作意外事件來接受。監(jiān)測風險征兆，并制定應急計劃，以確定 在風險發(fā)生時將采取何種行動。 2.5風險管理角色及職責風險管理角色及職責 2.5.1項目經(jīng)理 項目經(jīng)理對風險管理工作負全部責任。 2.5.2風險管理經(jīng)理 2.5.2風險管理經(jīng)理的工作就是警告項目風險，防止項目經(jīng)理和其他開發(fā)人員忽略風險管理。 2.5.2 2.5.2建議：建

10、議： 2.5.2一般大型項目（30 人以上），風險管理經(jīng)理應該全職；其它項目，風險管理經(jīng)理可以 兼職（但一般“項目經(jīng)理”不擔任此角色） 2.5.2 2.5.2項目組開發(fā)人員 項目組開發(fā)人員將被要求作為項目風險分析組的成員，對項目工作中存在的風險進行分析，并 整理成書面材料。 2.5.3SQA經(jīng)理 SQA 經(jīng)理將定期對風險管理工作開展情況進行評審，確保所開展的風險管理工作符合組織的要 求。 3.風險識別風險識別 （1）在項目計劃制定階段由項目風險管理經(jīng)理召開有項目風險分析組全體相關(guān)人員參 加的項目風險管理工作啟動會議（可以含在其它會議中進行）。 （2）在會議中，項目風險管理經(jīng)理向項目風險分析組全

11、體相關(guān)成員介紹項目風險分類 方法，并向所有到會人員分發(fā)一張項目風險分類表（見“2.2 風險種類”）或列出組 織建議的風險分類，供風險分析組成員在識別項目風險時使用。 （3）這次會議將通過討論，產(chǎn)生一個初步的項目風險清單，以便將來做進一步的分析。 “階段/迭代風險管理清單”的例子： 排 序 風險名 稱 停留 周數(shù) 風險描述 風險 得分 降低措施 責任 人 風險 狀態(tài) 1 2 排 序 風險名 稱 停留 周數(shù) 風險描述 風險 得分 降低措施 責任 人 風險 狀態(tài) 9 10 4.風險分析風險分析 風險分析的依據(jù)是“風險識別”出來的“風險清單”。 4.1發(fā)生的可能性發(fā)生的可能性 根據(jù)“風險清單”每一項，

12、項目組成員評估風險項，列出風險發(fā)生的可能性的三種狀態(tài)“非常 可能、可能發(fā)生、不太可能發(fā)生”，依據(jù)狀態(tài)填寫等級分“3、2、1”。 名 稱等級 非?？赡馨l(fā)生3 可能發(fā)生2 不太可能發(fā)生1 4.2影響的嚴重性影響的嚴重性 在評估了“發(fā)生可能性”后，項目組成員再根據(jù)“風險清單”每一項評估風險項，列出風險 影響嚴重性的四種狀態(tài)“非常嚴重、嚴重、中等、輕微”，依據(jù)狀態(tài)填寫等級分 “4、3、2、1”。 名 稱等級 非常嚴重4 嚴重3 中等2 輕微 1 5.風險的優(yōu)先級風險的優(yōu)先級 依據(jù)“發(fā)生可能性”和“影響的嚴重性”計算風險的得分，依據(jù)風險得分由高到低排列風險項 （如果得分相同，則項目組討論決定風險的前后順

13、序） 公式：風險得分公式：風險得分 = 發(fā)生可能性等級分發(fā)生可能性等級分 * 影響的嚴重性等級分影響的嚴重性等級分 注意：風險的優(yōu)先級只是一個估計值，不要在具體的得分和順序上爭論不下，優(yōu)先級劃分只是 幫助項目組發(fā)現(xiàn)前 10 大風險。 6.風險的控制風險的控制 6.1控制方法控制方法 6.1.1風險管理計劃 重點是制定一個計劃，以處理在排位靠前的高風險項。 風險管理計劃的例子： 序 號 風險 名稱 風險 得分 風險描述 誰引 起 發(fā)生 表現(xiàn) 可能 發(fā)生 時候 建議的降 低措施 責任 人 風險狀態(tài)/ 日期 備注：風險狀態(tài)：監(jiān)控、發(fā)生、關(guān)閉 風險管理計劃每階段/迭代重新評估一次。 風險監(jiān)控時選取風險

14、管理計劃中沒有關(guān)閉的前 10 大風險進行監(jiān)控即可。每階段/迭代啟動時， 選取“風險管理計劃”中處于“監(jiān)控”狀態(tài)的前 10 大風險，用于本階段/迭代的周例會上進行 跟蹤和監(jiān)控（注意：周例會時只監(jiān)控階段/迭代啟動時監(jiān)控的前 10 大風險）。 風險管理計劃的維護： 在周工作例會發(fā)現(xiàn)的新風險加入風險管理，重復“4 節(jié)，5 節(jié)”； 階段/迭代對風險進行進行重新評估，重復“3 節(jié)，4 節(jié)，5 節(jié)” 6.1.2風險的化解 避免風險避免風險（即：不要做冒險的活動） 將風險從系統(tǒng)的一部分轉(zhuǎn)移到另一部分將風險從系統(tǒng)的一部分轉(zhuǎn)移到另一部分（可能對于系統(tǒng)的其他部分此風險不會發(fā)生或發(fā)生 時影響不大） 購買關(guān)于風險的信息

15、購買關(guān)于風險的信息（例如：做實驗性項目，請咨詢專家等） 消除風險的根源消除風險的根源 接受風險接受風險（如果風險后果較小，而處理它可能代價很大，滾動處理可能是最有效的途徑） 發(fā)布風險發(fā)布風險（將風險發(fā)布給相關(guān)涉眾，如：管理者、市場人員、客戶特別注意策略等） 控制風險控制風險 制定風險無法化解時的“風險應急計劃” 分配額外的資源來處理風險 為處理風險留出額外的時間 等等 記住風險記住風險（未為將來的項目積累） 6.2風險監(jiān)控風險監(jiān)控 6.2.1周例會檢查風險 在周工作例會上，項目經(jīng)理需要跟蹤項目的風險。 1 根據(jù)風險列表，逐一分析前 10 大風險，確認已經(jīng)風險狀態(tài)是否“發(fā)生”或“關(guān)閉”； a)如果風險發(fā)生則啟動“