1、騰龍軟件騰龍.工程風險管理方案騰龍軟件：.；工程干系人分析四步法工程干系人分析四步法 IT軟件工程管理工程干系人分析四步法工程干系人分析四步法工程風險管理方案文件形狀： 草稿 正式發布 正在修正文檔編號：TL4070503當前版本：1.0作 者：李爽完成日期： DATE yyyy-MM-dd 2021-05-19版 本 歷 史版本/形狀作者參與者起止日期備注1.0正式發布李爽 DATE yyyy-MM-dd 2021-05-19目 錄 TOC o 1-3 h z HYPERLINK l _Toc260847599 0. 文檔引見 PAGEREF _Toc260847599 h 3 HYPERL

2、INK l _Toc260847600 0.1 文檔目的 PAGEREF _Toc260847600 h 3 HYPERLINK l _Toc260847601 0.2 文檔范圍 PAGEREF _Toc260847601 h 3 HYPERLINK l _Toc260847602 0.3 讀者對象 PAGEREF _Toc260847602 h 4 HYPERLINK l _Toc260847603 0.4 參考文獻 PAGEREF _Toc260847603 h 4 HYPERLINK l _Toc260847604 0.5術語與縮寫解釋 PAGEREF _Toc260847604 h 4

3、 HYPERLINK l _Toc260847605 1工程風險管理方案 PAGEREF _Toc260847605 h 4 HYPERLINK l _Toc260847606 1.1目的 PAGEREF _Toc260847606 h 4 HYPERLINK l _Toc260847607 1.2角色與職責 PAGEREF _Toc260847607 h 4 HYPERLINK l _Toc260847608 1.3啟動準那么 PAGEREF _Toc260847608 h 5 HYPERLINK l _Toc260847609 1.4輸入 PAGEREF _Toc260847609 h 5

4、 HYPERLINK l _Toc260847610 1.5主要步驟 PAGEREF _Toc260847610 h 5 HYPERLINK l _Toc260847611 1.5.1 風險識別 PAGEREF _Toc260847611 h 5 HYPERLINK l _Toc260847612 1.5.2 風險分析 PAGEREF _Toc260847612 h 5 HYPERLINK l _Toc260847613 1.5.3 風險減緩 PAGEREF _Toc260847613 h 5 HYPERLINK l _Toc260847614 1.5.4 風險監控 PAGEREF _Toc2

5、60847614 h 5 HYPERLINK l _Toc260847615 1.6輸出 PAGEREF _Toc260847615 h 6 HYPERLINK l _Toc260847616 1.7終了準那么 PAGEREF _Toc260847616 h 6 HYPERLINK l _Toc260847617 1.8度量 PAGEREF _Toc260847617 h 6 HYPERLINK l _Toc260847618 2實施建議 PAGEREF _Toc260847618 h 6 HYPERLINK l _Toc260847619 3附錄1：常見風險舉例 PAGEREF _Toc26

6、0847619 h 60. 文檔引見0.1 文檔目的0.2 文檔范圍0.3 讀者對象0.4 參考文獻提示：列出本文檔的一切參考文獻可以是非正式出版物，格式如下：標識符 作者，文獻稱號，出版單位或歸屬單位，日期0.5術語與縮寫解釋縮寫、術語解 釋1工程風險管理方案目的在工程的生命周期內，循環執行風險識別、風險分析、風險減緩和風險跟蹤，直到工程的一切風險都被識別與處理為止。角色與職責工程擔任人擔任風險管理。工程成員協助工程擔任人處置風險。啟動準那么曾經制定，工程研發曾經開場。輸入工程監控過程產生的文檔如、和等主要步驟 1.5.1 風險識別工程擔任人根據“風險跟蹤列表，定期例如每周一次識別本工程的風

7、險。1.5.2 風險分析工程擔任人評價每個風險的嚴重性、能夠性和風險系數，并按照風險系數從高到低的順序陳列風險。1.5.3 風險減緩對于風險系數超越“允許值建議為10的每一個風險，工程擔任人該當給出風險減緩措施，并指定責任人。風險系數越高，越先處置。1.5.4 風險監控工程擔任人跟蹤風險減緩過程，直到風險曾經處理為止。假設風險的性質發生變化，該當及時更新風險減緩措施輸出終了準那么一切風險都曾經處理，相關信息曾經記錄到之中。度量工程擔任人統計任務量。實施建議對風險管理過程域產生的一切有價值的文檔進展配置管理。工程擔任人根據本工程的特征，確定風險識別的頻度通常為每周一次，適當修正“風險登記表。選用

8、適宜的軟件工具，盡量減少風險管理過程域的任務量。工程監控和風險管理均由工程擔任人擔任，建議同步執行。附錄1：常見風險舉例 進度風險進度安排制定得能否合理？ WBS的分析能否足夠細，以便對進度做較貼切的安排？對交付日期的要求能否嚴厲？ 能否可以為了滿足嚴厲進度安排而對產品功能進展退讓放行？方案能否為過程管理預留時間？規模風險對產品的需求能否和涉眾認同一致？需求能否有優先級陳列？對需求的變化能否建立了相應的管理機制并實施？對需求的變化能否做相應的分析？需求能否穩定并到達了充分的共識？規模的估計方法能否正確掌握和運用？工程規模是固定不變還是在不斷擴展或變卦？ 工程開發規模或范圍預估能否正確？ 外部依

9、賴風險系統能否依賴于新的或未經實驗的產品、效力或技術？能否依賴于新的或未被證明的硬件、軟件或技術？ 對于與其他系統包括企業以外的系統的接口能否存在外部依賴性？該工程能否依賴于其他平行的開發工程？技術風險所采用技術能否曾經過運用？ 運用的組件能否被勝利的反復運用？反復運用的組件能否合理？ 數據量能否合理？當前可用的系統框架能否可以保管這些數據？ 能否有特殊或苛刻的技術需求如要求工程團隊處置他們不熟習的問題？能否存在極不靈敏的可用性和平安性需求如“系統必需永遠不出現缺點？系統的用戶能否對正在開發的系統類型沒有閱歷？運用程序的大小或復雜性能否導致了風險的添加？ 勝利能否依賴于開發工具設計工具、編譯器等和實施技術操作系統、數據庫、進程間通訊機制等的勝利集成。能否有替代方案，可以在沒有這些技術的情況下交付工程？人員能否獲得必要的人員測試人員、QA、SCM人員？ 工程人員能否具備適宜的技藝和閱歷以