1、項目風險管理計劃騰龍軟件項目風險管理計劃文件狀態： 草稿 正式發布 正在修改文檔編號：TL4070503當前版本：1.0作 者：李爽完成日期：2022-03-08版 本 歷 史版本/狀態作者參與者起止日期備注1.0正式發布李爽2022-03-08目 錄 0. 文檔介紹30.1 文檔目的30.2 文檔范圍30.3 讀者對象40.4 參考文獻40.5術語與縮寫解釋41項目風險管理計劃41.1目的41.2角色與職責41.3啟動準則51.4輸入51.5主要步驟51.5.1 風險識別51.5.2 風險分析51.5.3 風險減緩51.5.4 風險監控51.6輸出61.7結束準則61.8度量62實施建議63

2、附錄1：常見風險舉例60. 文檔介紹0.1 文檔目的0.2 文檔范圍0.3 讀者對象0.4 參考文獻提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：標識符 作者，文獻名稱，出版單位（或歸屬單位），日期0.5術語與縮寫解釋縮寫、術語解 釋1項目風險管理計劃1.1 目的在項目的生命周期內，循環執行風險識別、風險分析、風險減緩和風險跟蹤，直到項目的所有風險都被識別與解決為止。1.2 角色與職責l 項目負責人負責風險管理。l 項目成員協助項目負責人處理風險。1.3 啟動準則l 項目計劃已經制定，項目研發已經開始。1.4 輸入l 項目計劃l 項目監控過程產生的文檔如項目問題列表、項目質量

3、報告和項目周報等1.5 主要步驟 1.5.1 風險識別l 項目負責人根據“風險跟蹤列表”，定期（例如每周一次）識別本項目的風險。1.5.2 風險分析l 項目負責人評估每個風險的嚴重性、可能性和風險系數，并按照風險系數從高到低的順序排列風險。1.5.3 風險減緩l 對于風險系數超過“容許值”（建議為10）的每一個風險，項目負責人應當給出風險減緩措施，并指定責任人。風險系數越高，越先處理。1.5.4 風險監控l 項目負責人跟蹤風險減緩過程，直到風險已經解決為止。如果風險的性質發生變化，應當及時更新風險減緩措施1.6 輸出l 風險管理報告1.7 結束準則l 所有風險都已經解決，相關信息已經記錄到風險

4、管理報告之中。1.8 度量l 項目負責人統計工作量。2 實施建議l 對風險管理過程域產生的所有有價值的文檔進行配置管理。l 項目負責人根據本項目的特征，確定風險識別的頻度（通常為每周一次），適當修改“風險登記表”。l 選用合適的軟件工具，盡量減少風險管理過程域的工作量。l 項目監控和風險管理均由項目負責人負責，建議同步執行。3 附錄1：常見風險舉例 進度風險進度安排制定得是否合理？ WBS的分析是否足夠細，以便對進度做較貼切的安排？對交付日期的要求是否嚴格？ 是否可以為了滿足嚴格進度安排而對產品功能進行讓步放行？計劃是否為過程管理預留時間？規模風險對產品的需求是否和涉眾認同一致？需求是否有優先

5、級排列？對需求的變化是否建立了相應的管理機制并實施？對需求的變化是否做相應的分析？需求是否穩定并達到了充分的共識？規模的估計方法是否正確掌握和使用？項目規模是固定不變還是在不斷擴展或變更？ 項目開發規模或范圍預估是否正確？ 外部依賴風險系統是否依賴于新的或未經試驗的產品、服務或技術？是否依賴于新的或未被證明的硬件、軟件或技術？ 對于與其他系統（包括企業以外的系統）的接口是否存在外部依賴性？該項目是否依賴于其他（平行的）開發項目？技術風險所采用技術是否已經過使用？ 使用的組件是否被成功的重復使用？重復使用的組件是否合理？ 數據量是否合理？當前可用的系統框架是否能夠保存這些數據？ 是否有特殊或苛刻

6、的技術需求（如要求項目團隊處理他們不熟悉的問題）？是否存在極不靈活的可用性和安全性需求（如“系統必須永遠不出現故障”）？系統的用戶是否對正在開發的系統類型沒有經驗？應用程序的大小或復雜性是否導致了風險的增加？ 成功是否依賴于開發工具（設計工具、編譯器等）和實施技術（操作系統、數據庫、進程間通信機制等）的成功集成。是否有替代計劃，可以在沒有這些技術的情況下交付項目？人員是否獲得必要的人員（測試人員、QA、SCM人員）？ 項目人員是否具備合適的技能和經驗以及接受過相應培訓？ 項目人員是否會有突然接受其他任務的可能性？ 他們對項目成功是否有信心和決心？ 資金完成項目所需的資金能否到位？ 是否有預算限制