某軟件項目開發(fā)的風險評估案例目錄TOC\o"1-2"\h\u27158某軟件項目開發(fā)的風險評估案例 1157351.1風險定性評估 1293571.2風險定量評估 4193551.3風險評估結(jié)果 10常用的軟件項目風險評估方法有很多，可分為兩大類定性評估和定量評估。定性分析方法主要是通過分析需求分析階段、設計階段、編碼階段、集成和測試階段常見的風險因素，如在軟件需求分析階段有錯誤的理解需求開發(fā)錯誤的軟件系統(tǒng)設計困難實現(xiàn)的系統(tǒng)與客戶的需求不一致測試困難理解錯誤系統(tǒng)不穩(wěn)定編碼困難無法在規(guī)定的時間內(nèi)完成工作花費的時間長增加成本等風險因素。按照其發(fā)生的概率、對本階段目標的影響力、對其它階段目標的影響力，可以歸納出該風險相對軟件開發(fā)的綜合影響力。主要評定標準是從出現(xiàn)的概率的角度分為很高、高、一般、低、很低從對軟件項目的影響力角度來講分為很大、大、一般、小、很小。本章節(jié)通過采取定性風險評估和定量風評估方法，對表4.4最終得出的風險識別清單進行評估分析，并對風險要素進行排序，得出對項目風險影響較大的風險要素。1.1風險定性評估根據(jù)風險綜合的評價理論，針對上一節(jié)識別出的風險清單列表3.4進行定性分析。項目經(jīng)理和整個團隊使用頭腦風暴法對風險的影響和概率進行量化打分，并計算出風險程度如表1.1所示表1.1風險程度表編號識別代碼風險描述影響概率風險程度01RR-01需求不太明確或者不太完整，描述過于籠統(tǒng)。導致用戶、開發(fā)以及測試人員的理解不同，加劇了溝通成本0.860%0.4802RR-02需求頻繁變更，沒有確切的起始時間和結(jié)束時間，缺少對應的需求變更控制管理流程，隨意答應產(chǎn)品經(jīng)理修改。所有參與人貢不能拿到一個穩(wěn)定的文擋輸出0.860%0.4803RR-03需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別0.850%0.304RR-04需求管理不標準，以致于文本文檔錯亂、要求設計方案錯亂、沒有一個規(guī)范的需求管理文檔管理專用工具和步驟0.640%0.32續(xù)表1.1編號識別代碼風險描述影響概率風險程度05RR-05需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別0.830%0.2406TR-01項目技術架構(gòu)混亂復雜，或者說沒有架構(gòu)0.860%0.4807TR-02開始沒有統(tǒng)一的研發(fā)驚準規(guī)范，技術標準文培沒有，界面、代碼等設計編寫風格不統(tǒng)一0.660%0.3608TR-03重復性代碼較多，沒有建立可復用的模塊，也沒有人專口負責代碼定期的重構(gòu)0.580%0.4009TR-04軟件設計不符合面向?qū)ο笤O計的原則，各個模塊接日設計不統(tǒng)，軟件模塊間稱合性很髙，改動一處就會影喃很多地方0.670%0.4210PR-01沒有使用合適的項目管理工具來提高工作效率，比如代碼管理工具、文檔管理工具、bug管理工具等等。沒有自動化的系統(tǒng)集成工具。沒有使用配置管理工具，重復性工作太多，缺乏配置管理0.650%0.311PR-02沒有使用配置管理工具，重復性工作太多，缺乏配置管理0.780%0.5612PR-03沒有一套標準的開發(fā)管理流程，沒有確定項目標準，代碼管理混亂，各個階段研發(fā)狀態(tài)不明確0.770%0.4913MR-01領導力不足，項目管理經(jīng)驗不足，不能使團隊離效合作0.860%0.4814MR-02人員的組織結(jié)構(gòu)，分工，架構(gòu)分配不合理，角色分工不明確0.540%0.2015MR-03任務分配沒有發(fā)揮組員的特長，沒有讓正確的人做正確的工0.660%0.3616MR-04通管理有問題，溝通不暢。內(nèi)部協(xié)調(diào)效率低下。0.810%0.0817MR-05管理層對團隊的支持不夠，有效的推動溝通不足0.830%0.24根據(jù)公司項目實際情況以及通過對公司層面專家的訪談最后制定出的的風險概率影響矩陣見表1.2，并定義出風險影響程度。供各項目評估參考。表1.2風險概率影響矩陣風險影響程度可能帶來的后果風險發(fā)生概率80%60%50%30%10%0.8極高無法完成任務0.640.480.40.240.080.6高任務能正常完成，但是有嚴重影響，確定會延期0.480.360.240.180.06續(xù)表1.2風險影響程度可能帶來的后果風險發(fā)生概率80%60%50%30%10%0.5中等任務有可能延期0.40.30.250.150.050.3低對任務完成有一點影響0.240.180.150.090.030.1極低正常完成0.080.060.050.030.01風險等級：1．高于0.48為高風險2．介于0.24和0.4之間中等風險3．低于0.24為低等風險通過對比TC公司的風險概率影響矩陣表1.1，結(jié)合表1.2得出的風險識別結(jié)果，得到每個風險的風險等級表1.3如下。方便下一步根據(jù)風險等級做出相應的控制措施。表1.3風險等級表編號識別代碼風險描述影響概率風險程度優(yōu)先級01RR-01需求不是很明確或者不太完整，描述過于籠統(tǒng)。導致用戶、開發(fā)以及測試人員的理解不同，加劇了溝通成本0.860%0.48高02RR-02需求頻繁變更，沒有確切的起始時間和結(jié)束時間，缺少對應的需求變更控制管理流程，隨意答應產(chǎn)品經(jīng)理修改。所有參與人貢不能拿到一個穩(wěn)定的文擋輸出0.860%0.48高03RR-03需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別0.850%0.3中04RR-04需求管理不標準，以致于文本文檔錯亂、要求設計方案錯亂、沒有一個規(guī)范的需求管理文檔管理專用工具和步驟0.640%0.32中05RR-05需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別0.830%0.24低06TR-01項目技術架構(gòu)混亂復雜，或者說沒有架構(gòu)0.860%0.48高07TR-02開始沒有統(tǒng)一的研發(fā)驚準規(guī)范，技術標準文培沒有，界面、代碼等設計編寫風格不統(tǒng)一0.660%0.36中08TR-03重復性代碼較多，沒有建立可復用的模塊，也沒有人?？谪撠煷a定期的重構(gòu)0.580%0.40中續(xù)表1.3編號識別代碼風險描述影響概率風險程度優(yōu)先級09TR-04軟件設計不符合面向?qū)ο笤O計的原則，各個模塊接日設計不統(tǒng)，軟件模塊間稱合性很髙，改動一處就會影喃很多地方0.670%0.42中10PR-01沒有使用合適的項目管理工具來提高工作效率，比如代碼管理工具、文檔管理工具、bug管理工具等等。沒有自動化的系統(tǒng)集成工具。沒有使用配置管理工具，重復性工作太多，缺乏配置管理0.650%0.3中11PR-02沒有使用配置管理工具，重復性工作太多，缺乏配置管理0.780%0.56高12PR-03沒有一套標準的開發(fā)管理流程，沒有確定項目標準，代碼管理混亂，各個階段研發(fā)狀態(tài)不明確0.770%0.49高13MR-01領導力不足，項目管理經(jīng)驗不足，不能使團隊離效合作0.860%0.48高14MR-02人員的組織結(jié)構(gòu)，分工，架構(gòu)分配不合理，角色分工不明確0.540%0.20低15MR-03任務分配沒有發(fā)揮組員的特長，沒有讓正確的人做正確的工0.660%0.36中16MR-04通管理有問題，溝通不暢。內(nèi)部協(xié)調(diào)效率

低下0.810%0.08低17MR-05管理層對團隊的支持不夠，有效的推動溝通不足0.830%0.24低1.2風險定量評估定量風險分析過程的目的是定量分析每種風險的可能性及其對項目目標產(chǎn)生的后果，并分析項目的總體風險程度。此過程涉及的工作包括確定實現(xiàn)特定項目目標的可能性，確定項目面臨的風險，確定可能需要的成本和應急準備金計劃，確定每種風險對項目風險的相應貢獻以及分析風險。需要最關注的事情是尋找理想成本的風險可實現(xiàn)的業(yè)務目標的時間表和范圍。在本節(jié)中，在定性風險分析之后，使用層次分析法分析項目風險，確定風險權(quán)重，然后評估總體項目風險。層次分析過程(AHP)由美國運籌學專家和匹茲堡大學教授于本世紀提出。這是一種簡單的方法，結(jié)合了定性和定量分析，可以對更復雜的決策問題做出決策。特別是，它量化了決策者的經(jīng)驗判斷，這些決策者排列了人們思維過程的層次結(jié)構(gòu)，逐層比較了相關因素，并逐層檢驗了比較結(jié)果的合理性，從而提供了更具說服力的基礎。近年來，這種方法已在國內(nèi)外廣泛使用。分析層次結(jié)構(gòu)過程根據(jù)考慮的不同觀點，首先將比較元素劃分為層次結(jié)構(gòu)。例如，對于給定的業(yè)務決策A，可以從兩個方面B1和B2考慮，共有C1、C2、C3、C4這4種可選擇的方案，于是，該問題比較的層次化結(jié)構(gòu)圖如下AAB2B1C4C3C2C1圖1.1層次結(jié)構(gòu)圖運用層次分析法進行軟件項目風險評估的基本思路是首先找出軟件項目中風險問題所牽連的主要風險因素，將這些因素按其隸屬關系構(gòu)造成層次模型，建立判定矩陣，通過對矩陣中各因素之間定性的比較之后，給各個風險因素加上重要性權(quán)值，然后經(jīng)過定量計算得出每個風險因素相對重要性。通過分析我們得出TC公司軟件項目的層次如下表所示表4.4項目風險層次結(jié)構(gòu)一級二級三級項目總體風險需求風險RR-01需求不是很明確或者不太完整，描述過于籠統(tǒng)。導致用戶、開發(fā)以及測試人員的理解不同，加劇了溝通成本。RR-02需求頻繁變更，沒有確切的起始時間和結(jié)束時間，缺少對應的需求變更控制管理流程，隨意答應產(chǎn)品經(jīng)理修改。所有參與人貢不能拿到一個穩(wěn)定的文擋輸出。RR-03需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別。RR-04需求管理不標準，以致于文本文檔錯亂、要求設計方案錯亂、沒有一個規(guī)范的需求管理文檔管理專用工具和步驟。RR-05需求分析不夠，客戶參加不度不足，消用戶反饋的內(nèi)容無法得到立即回應，造成事后商品與用戶需求中間存有重特大差別。續(xù)表4.4一級二級三級項目總體風險技術風險TR-01項目技術架構(gòu)混亂復雜，或者說沒有架構(gòu)。TR-02開始沒有統(tǒng)一的研發(fā)驚準規(guī)范，技術標準文培沒有，界面、代碼等設計編寫風格不統(tǒng)一。TR-03重復性代碼較多，沒有建立可復用的模塊，也沒有人專口負責代碼定期的重構(gòu)。TR-04軟件設計不符合面向?qū)ο笤O計的原則，各個模塊接日設計不統(tǒng)，軟件模塊間稱合性很髙，改動一處就會影喃很多地方。過程風險PR-01沒有使用合適的項目管理工具來提高工作效率，比如代碼管理工具、文檔管理工具、bug管理工具等等。沒有自動化的系統(tǒng)集成工具。沒有使用配置管理工具，重復性工作太多，缺乏配置管理。PR-02沒有使用配置管理工具，重復性工作太多，缺乏配置管理。PR-03沒有一套標準的開發(fā)管理流程，沒有確定項目標準，代碼管理混亂，各個階段研發(fā)狀態(tài)不明確。管理風險MR-01領導力不足，項目管理經(jīng)驗不足，不能使團隊離效合作。MR-02人員的組織結(jié)構(gòu)，分工，架構(gòu)分配不合理，角色分工不明確。MR-03任務分配沒有發(fā)揮組員的特長，沒有讓正確的人做正確的工。MR-04通管理有問題，溝通不暢。內(nèi)部協(xié)調(diào)效率低下。MR-05管理層對團隊的支持不夠，有效的推動溝通不足。根據(jù)上面的表格我們可以畫出本公司軟件項目風險層次結(jié)構(gòu)圖如下圖1.2所示項目總體風險項目總體風險需求風險技術風險過程風險管理風險TR01TR02TR03PR01TR04PR02PR03MR02MR01MR03MR04MR05RR01RR02RR03RR04RR05圖1.2風險結(jié)構(gòu)圖有了上面的風險結(jié)構(gòu)圖，項目組的成員根據(jù)頭腦風暴法和專家評判法構(gòu)造出二級目標對比一級目標的對比矩陣如下表4.5所示表4.5二級目標對比一級目標對比矩陣表項目總體風險需求風險技術風險過程風險管理風險需求風險1.00002.00003.00004.0000技術風險0.50001.00002.00003.0000過程風險0.33330.50001.00002.0000管理風險0.25000.33330.50001.0000根據(jù)層次分析理論對矩陣表4.5，計算各個風險的權(quán)重，最大特征值和一致性比例如表4.6二級目標對比一級目標對比矩陣和權(quán)重項目總體風險一致性比例：0.0116對“項目總體風險”的權(quán)重：1.0000；λmax：4.0310項目總體風險需求風險技術風險過程風險管理風險權(quán)重(Wi)需求風險1.00002.00003.00004.00000.4673技術風險0.50001.00002.00003.00000.2772過程風險0.33330.50001.00002.00000.1601管理風險0.25000.33330.50001.00000.0954對二級目標的中間層要素進行排序得出下表4.6所示排序權(quán)重表格表4.7中間層要素排序矩陣中間層要素權(quán)重排序需求風險0.46731技術風險0.27722過程風險0.16013管理風險0.09544同樣的方法計算出三級指目標對二級目標的矩陣表，如下表4.7到表1.10表4.8需求風險三級目標對二級目標對比矩陣和權(quán)重需求風險一致性比例：0.0141對“項目總體風險”的權(quán)重：0.4673；λmax：5.0633需求風險RR-01RR-02RR-03RR-04RR-05WiRR-011.00002.00004.00005.00006.00000.4593RR-020.50001.00002.00003.00004.00000.2497RR-030.25000.50001.00002.00003.00000.1449RR-040.20000.33330.50001.00002.00000.0890RR-050.16670.25000.33330.50001.00000.0570表4.9技術風險三級目標對二級目標對比矩陣和權(quán)重技術風險一致性比例：0.0116對“項目總體風險”的權(quán)重：0.2772；λmax：4.0310技術風險TR-01TR-02TR-03TR-04WiTR-011.00002.00004.00005.00000.4593TR-020.50001.00002.00003.00000.2497TR-030.25000.50001.00002.00000.1449TR-040.20000.33330.50001.00000.0890表1.10過程風險三級目標對二級目標對比矩陣和權(quán)重過程風險一致性比例：0.0000對“項目總體風險”的權(quán)重：0.1601；λmax：3.0000技術風險PR-01PR-02PR-03WiPR-011.00001.00000.50000.2500PR-021.00001.00000.50000.2500PR-032.00002.00001.00000.5000表1.11管理風險三級目標對二級目標對比矩陣和權(quán)重管理風險一致性比例：0.0148對“項目總體風險”的權(quán)重：0.0954；λmax：5.0664需求風險MR-01MR-02MR-03MR-04MR-05WiMR-011.00000.25002.00003.00000.50000.1416MR-024.00001.00003.00006.00002.00000.4536MR-030.50000.20001.00002.00000.33330.0870MR-040.33330.16670.50001.00000.16670.0518MR-052.00000.50003.00006.00001.00000.2660通過上面的分析我們可以看出一致性校驗的數(shù)值都小于1，因此可以認為每個權(quán)重的風險數(shù)據(jù)是有效的，對比三級目標的權(quán)重進行全面的排序得出下表1.11的排序表表1.12風險要素對決策目標的排序權(quán)重識別代碼風險描述權(quán)重排序RR-01需求不是很明確或者不太完整，描述太寬泛。導致用戶、開發(fā)以及測試人員的理解不同，加劇了溝通成本。0.21461TR-02開始沒有統(tǒng)一的研發(fā)驚準規(guī)范，技術標準文培沒有，界面、代碼等設計編寫風格不統(tǒng)一。0.12952續(xù)表1.11識別代碼風險描述權(quán)重排序RR-02需求變更頻繁，沒有明確的起點巧終點，沒有相應的需求變更控制管理流程，隨意答應產(chǎn)品經(jīng)理修改。所有參與人貢不能拿到一個穩(wěn)定的文擋輸出。0.11673PR-03沒有一套標準的開發(fā)管理流程，沒有確定項目標準，代碼管理混亂，各個階段研發(fā)狀態(tài)不明確。0.08004TR-01項目技術架構(gòu)混亂復雜，或者說沒有架構(gòu)。0.07685RR-03需求分析不足，用戶參與度不夠，用戶反饋緩慢遲純，導致后期產(chǎn)品和用戶要求的出入很大。0.06776TR-03重復性代碼較多，沒有建立可復用的模塊，也沒有人專口負責代碼定期的重構(gòu)。0.04447MR-02人員的組織結(jié)構(gòu)，分工，架構(gòu)分配不合理，角色分工不明確。0.04338RR-04需求管理不規(guī)范，Ｗ至于文檔混亂、需求設計凌亂、沒有一個標準的需求管理文檔管理工具和流程。0.04169PR-02沒有使用配置管理工具，重復性工作太多，缺乏配置管理