1、2016年SPM05-軟件項目風險管理第一頁，共74頁。5.1.1 風險SEI將風險定義為損失的可能性。風險具有兩大屬性：可能性和損失。可能性是指風險發生的概率，損失是指預期與后果之間的差異。風險的根源在于事物的不確定性。第二頁，共74頁。軟件風險管理的相關概念目標:明確定義的目標界定了可接受的風險范圍。不確定性:未知的因素。損失:沒有潛在的損失，就沒有風險時間 選擇決策應對風險 第三頁，共74頁。導致軟件風險的原因進度過分緊迫；預算過分緊張；性能過分的超群，軟件可靠性要求過高；人員缺乏經驗，組織結構不適宜；期望過高而不現實；沒有明確或理解合同的條款；軟件規模估計不恰當；管理部門缺乏經驗；風險

2、分析和管理不恰當；缺乏政策性支持；不熟悉技術或過程；不熟悉必要的硬件；需求不一致（或定義不充分）；需求不斷變動；軟件開發計劃不恰當；軟件開發過程模型不適用；缺乏軟件工程技術和方法；缺乏自動化工具的支持6.1 軟件項目風險管理概述第四頁，共74頁。5.1.2 軟件風險軟件風險由管理過程風險和技術過程風險組成第五頁，共74頁。5.1.3 軟件項目風險管理風險管理與項目管理的關系可歸納如下：從項目的成本、時間和質量目標來看，風險管理與項目管理的目標一致。從項目管理的計劃職能來看，風險管理為項目計劃的制定提供了依據。從項目的成本管理職能來看，項目風險管理通過風險分析，指出有哪些可能的計劃外費用。從項目

3、實施過程來看，許多風險都在項目實施過程中由潛在變為現實。定出風險反應計劃。第六頁，共74頁。風險管理與項目管理的關系 目標一致為項目計劃的制定提供了依據是成本管理的一部分許多分析都在項目實施過程中由潛在變為現實6.1 軟件項目風險管理概述采購 計劃風險 計劃溝通計劃人力 計劃質量計劃 成本 計劃時間計劃集成計劃范圍計劃 項目 結束項目執 行控制 項目 計劃 項目 初始第七頁，共74頁。第八頁，共74頁。風險管理的主要內容【概述中提到】1、制定風險管理計劃2、風險識別3、風險分析4、風險計劃5、風險跟蹤6、風險應對7、風險管理驗證第九頁，共74頁。5.1.4 軟件項目風險管理意義141通過風險分

4、析,了解風險對項目的影響.為以后的規劃與設計工作提供反饋，以便采取措施防止與避免風險損失。可推動項目管理層和項目組織積累風險資料，以便改進將來的項目管理。 第十頁，共74頁。風險管理是指在項目進行過程中不斷對風險進行識別、評估、制定策略、監控風險的過程。通過風險識別、風險分析和風險評價去認識項目的風險，并以此為基礎合理地使用各種風險應對措施、管理方法、技術和手段對項目的風險進行有效的控制，妥善處理風險事件造成的不利后果，以最小的成本保證項目總體目標的實現。第十一頁，共74頁。5.2 風險識別是試圖通過系統化的方法尋找可能影響項目的風險（已知的和可預測的）以及確認風險特性的過程。目標是：辨識項目

5、面臨的風險，揭示風險和風險來源，以文檔及數據庫的形式記錄風險。活動包括：風險識別方法的確定；風險定義及分類；風險文檔編寫。第十二頁，共74頁。項目識別的依據項目計劃歷時經驗外部制度制約項目內部的不確定性第十三頁，共74頁。風險識別的輸入、輸出輸入標識風險評審風險輸出風險列表項目的WBS、工作的陳述（Statement Of Work，SOW）、項目相關信息、項目計劃假設、歷史項目數據，其他項目經驗文件、評審報告、公司目標等。第十四頁，共74頁。風險識別參與人員項目組成員風險管理人員學科專家（組織內）客戶項目的其他管理人員外部專家第十五頁，共74頁。常見軟件風險【142-143】人力資源風險需求

6、風險項目接口風險設計風險管理風險開發過程風險項目集成與測試風險第十六頁，共74頁。風險識別過程進行風險評估系統地識別風險風險定義及分類確定風險驅動因素將風險編寫為文檔第十七頁，共74頁。風險識別方法德爾菲方法頭腦風暴法情景分析法面談法會議法SWOT分析法風險條目檢查表第十八頁，共74頁。頭腦風暴法召開項目組全體會議，進行關于項目風險的自由討論，項目組成員在主持人的引導下完全自由地發言，不受限制，產生關于項目風險的概念。堅持不進行過多討論，不對別人的意見進行判斷性評論，甚至明確不許使用身體語言表達評判意見，如：咳嗽、冷笑等。險管理人員將會議結果進行分類整理，作為風險的基礎和其他風險識別方法的結果

7、一起提交風險分析。第十九頁，共74頁。情景分析法通過對系統內外相關問題的系統分析，設計出多種可能的未來前景，然后用類似于撰寫電影劇本的手法，對系統發展態勢做出自始至終的情景和畫面的描述。可用情景分析法來預測和識別其關鍵風險因素及其影響程度。第二十頁，共74頁。SWOT分析法(Strength, Weakness, Opportunities, and Threats) 是綜合分析項目內部優勢、弱勢和項目外部機會與威脅的技術。SWOT作為一種系統分析工具，其主要目的是對項目的優勢與劣勢、機會與威脅各方面，從多角度對項目風險進行識別。第二十一頁，共74頁。風險條目檢查表利用一組提問來幫助管理者了解

8、項目在各方面有哪些風險。檢查表中，列出了所有可能的與每一個風險因素有關的提問，使得風險管理者集中來識別常見的、已知的和可預測的風險條目檢查表一般根據風險要素進行編寫，建立軟件項目的風險條目列表，包括項目的環境、管理層的重視度、技術情況以及內部因素(如團隊成員的技能或技能缺陷等)。 第二十二頁，共74頁。第二十三頁，共74頁。一、產品工程類Requirements（需求）Stability（穩定性）Completeness（完整性）Clarity（清晰）Validity（有效性）Feasibility（可行性）Precedent（案例）Scale（規模）第二十四頁，共74頁。Design（設計）

9、Functionality（功能性）Difficulty（困難）Interfaces（接口）Performance（性能）Testability（可測試性）Hardware Constraints（硬件約束）Non Developmental software（非開發軟件）第二十五頁，共74頁。Code and Unit test（編碼和單元測試）Feasibility（可行性）Testing（單元測試）Coding/Implementation（編碼/實現）Integration and Test（集成和測試）Environment（環境）Product（產品）System（系統）第二十六頁

10、，共74頁。Engineering Specialties（工程特點）Maintainability（可維護性）Reliability（可靠性）Safety（安全性）Security（保密性）Human Factors（人的因素）Specification（特定性）第二十七頁，共74頁。二、Development Environment（開發環境）Development process（開發過程）Formality（正規性）Suitability（適宜性）Process Control（過程控制）Familiarity（熟悉程度）Product control（產品控制）第二十八頁，共74頁。

11、Development System（開發系統）Capacity（生產量）Suitability（適宜性）Usability（可用性）Familiarity（熟悉度）Reliability（可靠性）System Support（系統支持）Deliverability（可交付性）第二十九頁，共74頁。Management Process（管理過程）Planning（計劃）Project Organization（項目組織）Management Experience（管理經驗）Program Interfaces（項目接口）第三十頁，共74頁。Management Methods（管理方法）Mon

12、itoring（監控）Personnel Management（人事管理）Quality Assurance（質量保證）Configuration Management（配置管理）第三十一頁，共74頁。Work Environment（工作環境）Quality Attitude（質量態度）Cooperation（合作）Communication（交流）Morale（士氣）第三十二頁，共74頁。三、Program Constraints（項目約束）Resources（資源）Schedule（進度）Staff（人員）Budget（預算）Facilities（設施）第三十三頁，共74頁。Contra

13、ct（合同） Type of Contract（合同類型）Restriction（約束）Dependence（依賴關系）第三十四頁，共74頁。Program Interfaces（項目接口）Customer（客戶）Associate Contractors（聯合承包方）Subcontractors（子承包方）Prime Contractor（主承包方）Corporate Management（共同管理）Vendors（供貨商）Politics（策略）第三十五頁，共74頁。5.3 風險分析提煉風險背景，確定風險來源，確定行動時間框架和確定前10相首要風險名單5.3.1 風險分析過程第三十六頁，共

14、74頁。5.3.1 風險分析過程定義風險度量準則預測風險影響評估風險對風險進行排序制定風險計劃【設想、應對】第三十七頁，共74頁。分析風險發生的概率，確定發生的可能性（P）風險后果，發生后對項目目標的影響（I）風險值，風險的嚴重程度R=F(P,I)確定優先次序按風險的嚴重性排序確定最需要關注的TOP 10風險第三十八頁，共74頁。前10位首要風險列表第三十九頁，共74頁。制定風險計劃第四十頁，共74頁。風險列表示例第四十一頁，共74頁。5.3.2 風險分析技巧與工具一般，在定性風險分析之后就可以進行定量風險分析。定量風險分析量化分析每一個風險的概率及其對項目目標造成的后果，也分析項目總體風險的

15、程度。方法：訪談、因果關系分析、決策樹分析、模擬法第四十二頁，共74頁。因果關系分析第四十三頁，共74頁。決策樹分析提供項目所有可供選擇的行動方案，行動方案之間的關系，行動方案的后果以及發生的概率提供選擇一個最佳的方案的依據損益期望值(Expected Monetary Value，EMV)是決策樹的一種計算值，根據風險發生的概率計算例如：某行動方案成功的概率是50%，收益是10 EMV=1050%=5第四十四頁，共74頁。決策樹分析風險值？EMV=0失敗：P=30%, outcome= -200000 成功：P=70%EMV=9500070%=66500實施后：EMV=6500不實施EMV=

16、-20000030%=-60000低性能：P=70%, outcome=-100000EMV=-10000070%=-70000高性能：P=30%, outcome=550000EMV=55000030%=1650006.3 風險評估第四十五頁，共74頁。決策樹分析例子6.3 風險評估第四十六頁，共74頁。差距分析法【151】帕累托分析法敏感度分析法【152】第四十七頁，共74頁。5.3.3 分析成果6.3 風險評估第四十八頁，共74頁。5.4 風險跟蹤與應對5.4.1 風險跟蹤的目標和依據5.4.2 風險跟蹤的成果5.4.3 風險跟蹤的過程第四十九頁，共74頁。風險控制通過對風險的規劃和對項

17、目全過程的控制，保證風險管理能達到預期的目標。其目的是核對風險管理的策略和實施的實際效果是否和預見相同，同時獲取反饋信息，改善風險計劃和管理。第五十頁，共74頁。5.4.3 風險跟蹤的過程監視風險設想對比項目狀態與風險閾值風險信息的通知報告風險的度量第五十一頁，共74頁。風險度量及定義6.5 風險控制第五十二頁，共74頁。風險應對計劃（top 10 清單）6.5 風險控制任務可能的風險產生的階段產生的原因避免的措施后處理制定設計階段的規范和標準時間風險項目準備需制定的規范和標準較多，而同時需完成其他工作，使得可使用的時間和資源有限開發環境確認資源風險系統設計由于設備未到位導致延誤開發管理系統設

18、計技術風險系統設計基于TeMIP平臺開發SDH專網管理系統對于公司乃至國內都是全新的課題，由于技術的掌握程度和經驗仍很欠缺在系統設計前請TeMIP專家進行相關培訓換成其他的技術實現第五十三頁，共74頁。應對計劃（top 10 清單）實例（續）任務可能的風險產生的階段產生的原因避免的措施后處理對功能規格和系統設計的調整時間風險0版本開發評測結果對功能規格和系統設計影響較大0版本開發時間風險0版本開發由于學習曲線過長延誤時間系統測試資源風險0版本開發開發人員與SQA人員對工作站和服務器使用的爭奪MD現場調試資源風險1版本開發由于設備問題延誤現場調試現場運行環境確認資源風險2版本開發由于設備問題延誤

19、驗收測試的進行第五十四頁，共74頁。風險管理是一個連續的過程6.5 風險控制第五十五頁，共74頁。5.4.4 風險應對策略避免是指通過改變項目計劃或條件完全消除項目風險或保護項目目標不受風險影響。轉移是指風險轉移給另一方去承擔。緩解是指尋求降低一個不利風險事件的發生概率或使它產生的后果達到一個可接受的水平接受是指有意識地選擇承擔風險后果，或者項目組找不出任何風險反應策略。風險研究是指通過調查研究以獲得更多信息的風險應對策略。風險儲備是指對項目意外風險預留應急費用和進度計劃。假如風險影響巨大，或者采取的措施不完全有效，這種情況下就要開發風險退避計劃。第五十六頁，共74頁。5.4.5 風險應對過程

20、對觸發事件作出反應【定期事件、時間、相對變化、閾值觸發器】執行風險計劃對照計劃，報告進展修正與計劃的偏差第五十七頁，共74頁。5.5風險管理驗證評審風險計劃：計劃的質量一定程度上決定著結果的質量。計劃應滿足下列要素：完整性、可理解性、詳細程度、 一致性、現實性審計管理過程【三種標準：ISO9000、SEI-CMM和MIL-STD-498】風險管理回報第五十八頁，共74頁。5.6 風險管理實踐以一個教育管理系統項目為例。某教育管理系統項目是一個基于J2EE技術的Web應用項目。它主要為個公司或者一個部門的所有員工提供教育培訓的管理。這個項目的需求來自一家大型公司，我們要在規定期限內提交產品，并保

21、證軟件的質量。教育管理系統項目項目被劃分成多個較小的模塊或單元，分配給項目的各個小組的成員，每個小組成員承擔一個或幾個任務。第五十九頁，共74頁。功能分解第六十頁，共74頁。風險分析風險分析是在事前的一種估計，憑借一定的技術手段和豐富的經驗，基本能夠對項目的風險做出比較準確的估計，經過慎重的考慮提出可行的風險回避措施。下面主要關注軟件開發中的主要風險，但是這只是項目風險中的一部分，在資金、預算、合同等方面都存在風險。項目過程中在幾乎每個階段都會出現風險。正確評估每個階段可能的風險是保證項目按時按質完成的重要環節。第六十一頁，共74頁。問題：請分析軟件開發各個階段的風險第六十二頁，共74頁。需求

22、分析階段的風險以用戶的需求開始，以書面的形式形成 用戶需求。需求分析更多的是開發方確認需求的可行性和一致性的過程，在此階段需要和用戶進行廣泛的交流和確認。需求和需求分析的任何疏漏造成的損失會在軟件系統的后續階段被一級級地放大，因此本階段的風險最大。第六十三頁，共74頁。設計階段的風險需求分析的不完整和錯誤，在設計階段被成倍地放大。設計階段的主要任務是完成系統體系結構的定義，使之能夠完成需求階段的即定目標；另一方面也是檢驗需求的一致性和需求分析的完整性和正確性。設計本身的風險主要來自于系統分析人員。分析人員在設計時過于定制，系統的可擴展性較弱，會給后期維護帶來巨大的負擔。 設計階段蘊涵的另一種風

23、險來自于設計文檔。文檔的不健全，這不僅會造成實現階段的困難，更會在后期的測試和維護造成災難性的后果，例如根本無法對軟件系統進行版本升級，甚至是發現的簡單錯誤都無從更正。 第六十四頁，共74頁。開發測試階段的風險軟件的實現從某種意義上講是軟件代碼的生產。代碼本身也是文檔的一部分，同時它又是將來運行于計算機系統之上的實體。源代碼書寫的規范性，可讀性是該階段的主要風險來源。規范的代碼生產會把屬于程序員自身個性風格的成分引入代碼的比例降到最低限度，從而減小了系統整合的風險。第六十五頁，共74頁。維護階段的風險從軟件工程的角度看，軟件維護費用約占總費用的 55%-70%。對系統可維護性的輕視是大型軟件系統的最大風險。在軟件漫長的運營期內，業務規則肯定會不斷發展，科學的解決此問題的做法是不斷對軟件系統進行版本升級，在確保可維護性的前提下逐步擴展系統。在軟件系統運營期間，主要的風險源自于技術支持體系的無效運轉。科學的方法是有一支客戶支持隊伍不斷收集運行中發現的問題，并將解決問題的方法傳授給軟件系統的所有使用者。第六十六頁，共74頁。體系結構方面的風險本項目采用J2EE技術和三層結構，在技術的成熟度上來說，不存在風險。但是，在實現上，對開發人員的技術要求，以及在實現良好的軟件構架和穩定的組件方面，也存在風險性。軟件體系結構影響到軟件的如下質量因素：軟件的可伸