軟件工程原理與實踐（碩士）課件 08 軟件風險管理

高級軟件工程

SoftwareEngineering軟件風險管理軟件項目充滿了風險這是一個VUCA的時代、不確定的時代不確定(Uncertain)易變性(Volatile)變化的不確定性復雜(Complex)結果的不確定性模糊(Ambiguous)當前或未來情況的不確定性風險就是不確定的事件2軟件項目風險示例威脅用戶需求常常被誤解，使得項目大量返工突然遇到了以前未發(fā)現(xiàn)的技術難題項目范圍總是在變，失控了糟糕的計劃與估算導致項目嚴重誤期、成本超預算軟件有大量的bug，故障頻發(fā)技術骨干流失了……機會不少用戶開始放棄線下會議，而采用在線會議軟件甲方有意向增加新的投資剛出現(xiàn)了預訓練模型的新技術，據(jù)報導不少AI算法的精度大幅度得以提高公司新招聘了新的開發(fā)人員另一個項目組剛搭建了持續(xù)集成工具鏈，使得系統(tǒng)集成和上線的速度得到了提升……3軟件風險案例分析你們的大作業(yè)項目的最大風險是什么？4代碼大模型

三維操作系統(tǒng)

Segway自動平衡車02-風險管理的成熟度模型01-基本概念03-風險管理流程5風險的概念風險是一種不確定的事件或條件，一旦發(fā)生，會對至少一個項目目標造成影響，如范圍、進度、成本和質量。事件可能性影響高風險中等風險低風險小大影響低高可能性事件6軟件風險管理軟件風險管理的定義：對影響軟件項目、過程或產(chǎn)品的風險進行評估和控制的實踐過程。軟件風險管理是管理和開發(fā)軟件系統(tǒng)必不可少的要素：軟件風險是工作與生俱來的；軟件風險隨著系統(tǒng)復雜程度的增加而增加；軟件風險影響人們實現(xiàn)目標。沒有風險管理是最大的風險！7不同的風險承受力投資大小成功的概率1.00.0守成者冒險者風險中立者小大8風險策略被動風險策略（reactiveriskstrategy）被戲稱為“印地安那·瓊斯學派的風險管理”。印地安那·瓊斯在以其名字為影片名的電影中，每當面臨無法克服的困難時，總是一成不變地說：“不要擔心，我會想出辦法來的！”。主動風險策略（proactiveriskstrategy）早在項目啟動之前就已經(jīng)開始了，識別出潛在的風險，評估它們出現(xiàn)的概率及產(chǎn)生的影響，并且按重要性加以排序；然后建立一個計劃來預防風險，以及在風險發(fā)生時采取有效的應急措施。風險策略的主動度多少才合適呢？這就要看風險的投資回報率。9風險管理的成本和收益風險管理是一種投資，它是為減輕潛在的不利事件或增加潛在的有利事件對項目的影響而采取的一項活動。風險投資回報率（ROIRM）＝收益/成本成本是為風險評估和控制投入的所有資源，包括評估風險、舉行風險管理會議、制定和實施風險管理計劃、風險發(fā)生時的應急措施、報告風險信息等的成本。收益是指實施風險管理后所帶來的收益和損失減少。據(jù)統(tǒng)計，軟件開發(fā)的風險投資回報率的基準大于20，因此，對于大多數(shù)軟件項目，應積極進行主動風險管理。1002-風險管理的成熟度模型01-基本概念03-風險管理流程11風險管理的成熟度模型防范階段(3)問題階段(1)緩和階段(2)機會階段(5)預知階段(4)12第一級：問題階段危機管理、救火模式人們忙于解決問題，沒有時間考慮將來風險(威脅)直到演變?yōu)閱栴}后才著手處理管理層沒有意識到風險，或者對風險可能發(fā)生的時間估計有誤管理層一聽說風險，就責怪報告者，因此大部分人不會報告壞消息我疲于救火!13第二級：緩和階段引入了風險概念對風險管理了解不多，而且缺乏經(jīng)驗沒有有計劃地應對風險經(jīng)理們采用應急計劃以減少重大威脅發(fā)生的可能性或后果我想知道什么會出錯!14第三級：防范階段風險管理從經(jīng)理的活動變?yōu)樾〗M的活動主動管理，識別和消除威脅的根源大部分人有經(jīng)驗，能識別威脅，但對于如何量化風險沒有把握。我想采取行動以便不留遺憾!15第四級：預知階段量化的風險管理項目小組和客戶運用風險管理，以合理的精度量化風險，以便能集中精力解除最關鍵的風險。主動迎接風險和評估備用方案我想知道成功的機會有多大!16第五級：機會階段風險不一定是消極的，有風險的地方也蘊藏著機會風險被看作節(jié)約費用和比計劃做得更好的機會風險，像質量一樣，人人有責在開放和沒有壓力的環(huán)境中不斷地識別、交流和應對風險我想超過我自已的期望!1702-風險管理的成熟度模型01-基本概念03-風險管理流程18風險管理流程RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks19RiskStatementIdentify風險識別RiskDatabase,RiskConceptsandProcessesIdentifyLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks20RiskStatement風險識別方法核對清單訪談頭腦風暴Delphi法會議評審日常輸入調(diào)查工作小組21項目各階段典型威脅事件啟動階段計劃階段執(zhí)行階段收尾階段缺少相應專業(yè)的專家對需求界定不清沒有做可行性研究目標不清沒有風險管理計劃倉促計劃缺少管理層支持職能界定差項目隊伍缺乏經(jīng)驗人員技能不夠材料短缺人員誤工天氣影響范圍改變項目進度改變環(huán)境要求沒有適當?shù)目刂企w系產(chǎn)品或服務質量差客戶不能接受成果現(xiàn)金流出現(xiàn)問題風險發(fā)生最高時期風險影響最高時期概率影響度時間各階段典型的風險事件風險價值22十大軟件風險(威脅)需求誤解缺少上層的支持需求變更失控未能合理管理客戶期望值不現(xiàn)實的進度計劃和成本預算質量低劣人員薄弱技術和架構風險軟件外包失敗缺乏足夠的用戶參與23風險列表（示例）No條件結果1開發(fā)進度緊迫可能會犧牲質量換取時間2需求變更頻繁大量的返工3開發(fā)人員遇到生疏的前端React框架開發(fā)時間將拉長4開發(fā)團隊被分隔在上海和北京兩地團隊內(nèi)部的交流將更加困難5開發(fā)人員同時擔任測試角色更多bug未被發(fā)現(xiàn)24風險分析與劃分優(yōu)先級RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks25RiskStatementIdentify風險分析分析內(nèi)容風險發(fā)生概率和可能性風險影響度風險暴露量=發(fā)生概率*影響度預測一組臨界點以定義項目終止區(qū)域建立預警閾值26可能性定義為百分數(shù)、一個詞組或一個相對數(shù)字五分制詞語百分比1極不可能幾乎沒有機會1-20%2不可能可能不是21-40%3我們懷疑有點可能41-60%4可能我們相信61-80%5幾乎一定非?？赡?gt;80%27影響度從四個風險因素分析影響度：性能產(chǎn)品能夠滿足需求且符合于其使用目的的不確定的程度成本項目預算能夠被維持的不確定的程度進度項目進度能夠被維持且產(chǎn)品能按時交付的不確定的程度支持軟件易于糾錯、適應及增強的不確定的程度28影響度評估成本進度支持性能低(0~29)低于1%落后1周稍有影響稍有影響中(30~59)低于5%落后2周有一定影響有一定影響高(60~79)低于10%落后1月有嚴重影響有嚴重影響關鍵(80~100)≥10%落后1月以上無法進行支持無法完成任務因素級別29概率－影響矩陣影響概率5102040800.9591836720.7471428560.5351020400.323612240.111248風險暴露量=概率*影響度30風險優(yōu)先級可按風險暴露量排序，生成粗略的風險優(yōu)先級列表可將影響最大的風險排在前面可將一些關聯(lián)的風險排在前面重點考慮前10名的風險31更新后的風險列表(示例)按風險等級從高到低排序等級分類緊迫性條件結果概率影響暴露量高進度中開發(fā)進度緊迫可能會犧牲質量換取時間80%6048高需求高需求變更頻繁大量的返工60%8048中技術中開發(fā)人員遇到生疏的前端React框架開發(fā)時間將拉長90%4036中組織高開發(fā)團隊被分隔在上海和北京兩地團隊內(nèi)部的交流將更加困難80%4032低角色低開發(fā)人員同時擔任測試角色更多bug未被發(fā)現(xiàn)80%201632風險管理計劃RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks33RiskStatementIdentify威脅的應對策略上報。如果某威脅不在項目范圍內(nèi)，或提議的應對措施超出了項目經(jīng)理的權限，就應采用上報策略。規(guī)避。采取行動來消除威脅或不受之影響。轉移。把某風險的部分或全部消極影響連同應對責任轉移給第三方。減輕。把不利風險事件的概率和/或影響降低到可接受的臨界值范圍內(nèi)。接受。因為幾乎不可能消除項目的全部威脅，所以就需要采用風險接受策略。被動接受風險，只需要記錄本策略，而不需要任何其他行動；待風險發(fā)生時再由項目團隊進行處理。主動接受策略是建立應急儲備，安排一定的時間、資金或資源來應對風險。34機會的應對策略上報。如果某機會不在項目范圍內(nèi)，或提議的應對措施超出了項目經(jīng)理的權限，就應采用上報策略。開拓。采取行動來確保把握住高優(yōu)先級的機會。分享。將應對機會的責任轉移給第三方，使其享有機會所帶來的部分收益。提高。提高機會出現(xiàn)的概率和（或）影響。接受。承認機會的存在，但不主動采取措施。被動接受風險，只需要記錄本策略，而不需要任何其他行動；待風險發(fā)生時再由項目團隊進行處理。主動接受策略是建立應急儲備，安排一定的時間、資金或資源，以便在機會出現(xiàn)時加以利用。35風險應對措施示例1

使用公司后備風險基金（接受）在項目預算中設置不可預見費（接受）購買商業(yè)保險（轉移）必要時補充或修改合同條款保證公司的利益（減輕）必要時可以將合同中風險較大的那一部分分包出去（轉移）多種技術方案（減輕）選擇低風險方案（回避）對已經(jīng)發(fā)生嚴重延期的項目緊急補充人力（接受）36風險應對措施示例2風險#1：進度風險a.減輕：采用歷史數(shù)據(jù)，基于經(jīng)驗模型進行科學的估算，和項目干系人進行有效溝通，建立切合實際的進度計劃；對需求劃分優(yōu)先級，采用迭代開發(fā)過程，優(yōu)先級高的需求在前面的迭代實現(xiàn)，同時通過迭代使集成和測試提前，以保證質量。b.接受：當進度落后超過10%時，及時分析原因，進行改進；當進度落后超過20%時，刪除一些優(yōu)先級最低的需求，決不犧牲質量。371）需求誤解后果開發(fā)出的軟件被客戶否定而不得不返工。原因開發(fā)人員與客戶的交流不夠順暢；客戶未能把其需求準確、完整地陳述出來，遺漏了一些需求；自然語言表述的需求具有嚴重的二義性，使不同的讀者對其的理解不一致；客戶不能完全理解開發(fā)人員撰寫的需求規(guī)約文檔，未能發(fā)現(xiàn)需求的許多缺陷等。緩解措施采用訪談、研討會、問卷調(diào)查等多種方式開展充分的需求調(diào)研，盡可能全面完整地獲取需求；細致分析需求，建立術語表，使用詳盡、準確的詞匯描述需求，采用UML等（半）形式化語言進行需求建模；建立界面原型，以形象易懂的形式和用戶進行溝通，獲得用戶的反饋；組織客戶、最終用戶、架構師、測試工程師、領域專家等對需求進行評審，盡早發(fā)現(xiàn)需求的缺陷；早期編寫用戶手冊和測試用例，也是驗證需求的一種有效方法。382）缺少上層的支持后果組織內(nèi)部的其他上層人員會強迫項目組接受不現(xiàn)實的項目目標，或者進行不合理的變更，造成項目的失敗。緩解措施和上層進行積極溝通，了解、理解和滿足上層的需求和期望；讓上層了解項目的意義和重要性，以獲得上層的重視；有計劃、高質量地開發(fā)軟件，切實履行承諾，以獲得上層的信任；定期向上層匯報項目進展和風險狀態(tài)，提供項目良好的可視性；遇到問題，能提出建設性意見或解決方案，而不是停留在抱怨或反映的層面；適時向上層正式和非正式地培訓軟件開發(fā)過程和方法，使其能支持有效的軟件開發(fā)實踐。393）需求變更失控后果對項目的進度、人力資源、經(jīng)費、質量等產(chǎn)生很大的影響原因變更是軟件開發(fā)所固有的，平均每個軟件項目會有25%的需求變更?？赡軐π枨笥辛烁钊氲恼J識、市場可能發(fā)生變更、項目的資源可能發(fā)生變動、以及發(fā)現(xiàn)了需求中的缺陷需要糾正等等。緩解措施開展充分的需求調(diào)研，盡可能完整地、準確地獲取和定義需求，以避免由于錯誤而變更需求；把需求排出優(yōu)先級，根據(jù)項目進度和預算，選擇優(yōu)先級高的需求，建立一個與目標一致的需求基線；采用迭代開發(fā)過程，優(yōu)先級高的需求在前面的迭代實現(xiàn)。當需求發(fā)生變更時，把變更的需求和現(xiàn)有的需求放在一起，重新排序。若進度來不及時，可拋棄優(yōu)先級最低的需求；按變更控制流程對需求變更進行有效的控制，確保采納最合適的變更，使變更產(chǎn)生的負面影響減少到最小；采取針對變更的設計策略，例如模塊化、信息隱藏等，提高軟件的可維護性，使變更引起的修改盡可能限制在局部范圍內(nèi)。404）未能合理管理客戶期望值后果軟件開發(fā)中的諸多問題，大都源于客戶對項目持有的不現(xiàn)實的期望。StandishGroup的一項調(diào)查表明，10%的項目由于這個原因被取消了。緩解措施了解并理解客戶的需求和期望?？蛻舻囊蠓譃槊鞔_的需求和隱含的期望，如果我們只是了解并努力滿足客戶的需求，最多只能達到客戶一般的滿意水準，要能使客戶非常滿意或是給客戶帶來喜悅，應更好地了解并理解客戶的期望；培訓客戶以使他們更好地理解軟件開發(fā)過程。客戶對開發(fā)的認識，有助于開發(fā)人員和他們一起商討建立合理的、現(xiàn)實的項目目標和計劃；開發(fā)人員應采用歷史數(shù)據(jù)進行科學的進度和成本估算，盡量客觀準確地設定自己的期望，不要盲目樂觀，以免客戶有不現(xiàn)實的期望。415）不現(xiàn)實的進度計劃和成本預算后果讓開發(fā)人員縮短關鍵性的前期開發(fā)活動，例如需求和設計，從而導致后期大量的返工；同時它也向開發(fā)人員施加了額外的壓力，給開發(fā)人員的自信和生產(chǎn)率造成長期的、巨大的傷害。緩解措施詳細分析需求，采用歷史數(shù)據(jù)，基于經(jīng)驗模型進行科學的估算?？捎啥鄠€估算師獨立估算，再進行綜合；和項目干系人進行有效溝通，根據(jù)估算和目標，選擇優(yōu)先級高的需求，確定項目范圍，建立切合實際的進度計劃；采用迭代開發(fā)過程，把優(yōu)先級高的需求在前面的迭代實現(xiàn)。當進度延誤時，寧可取消優(yōu)先級低的需求，也不犧牲質量；采用基于復用的軟件開發(fā)方法，在需求、設計、編碼、測試和管理等多個方面復用已有的成果，例如：框架、設計模式、構件、代碼、測試案例等等。通過復用，可以節(jié)省成本，加快開發(fā)進度；同時這些可復用成果在多個應用中被反復使用，質量更好。426）質量低劣后果當項目達到功能完成的里程碑時，不得不為質量而大量返工，其代價是原來的3~10倍。原因當開發(fā)進度緊張、預算和資源不足等情況下，開發(fā)人員常常會減少質量保證措施，犧牲質量。緩解措施開展多層次的測試，包括單元測試、集成測試和系統(tǒng)測試，特別對易錯模塊重點進行測試。這些易錯模塊僅占總代碼量的20%，但卻隱藏了80%的缺陷；對需求、設計、源代碼、計劃和測試用例等進行評審，評審的方法有審查、走查、結對評審、桌查、輪查、小組評審等；采用迭代開發(fā)過程，讓測試提前進行，及早發(fā)現(xiàn)問題；除此之外，還有靜態(tài)分析、質量審核、形式化證明等技術，都能有效保證質量。437）人員薄弱現(xiàn)象人數(shù)不足人員的能力欠佳士氣低下缺乏各種角色的齊心協(xié)力人員流失率過高后果極大影響了開發(fā)的進度、成本和質量。緩解措施招聘高級人才。不同軟件開發(fā)人員的生產(chǎn)率水平會相差10倍甚至20倍，因此，在軟件行業(yè)中，招聘1個“諸葛亮”可以頂上20個“臭皮匠”，同時還節(jié)省了管理和溝通成本；開展團隊建設，激勵士氣，培養(yǎng)高業(yè)績團隊；進行有計劃的培訓，不斷提升人員的能力和素質；在項目啟動前，提前預定關鍵的開發(fā)人員，確保足夠的核心人員；必要時，可以和其他組織合作，通過人員外包方式增加開發(fā)人手；留住人才，幫助其不斷成長。448）技術和架構風險后果如果技術方案或軟件架構不妥，就會導致軟件大規(guī)模的返工；如果過高估計新技術或方法帶來的效率，就會導致采購浪費和過于樂觀的計劃。緩解措施評審。組織技術人員和專家等，對技術方案或軟件架構進行評審，及早發(fā)現(xiàn)缺陷；可行性原型。如果預計采用的技術和架構對項目組來說是新的，或者在新領域中進行應用，則應預先開發(fā)技術（或架構）原型，驗證通過了才能采用；向專家咨詢。咨詢已掌握該技術或架構的專家，這能使項目組快速學習和掌握新的知識。459）軟件外包失敗現(xiàn)象外包方推遲交付時間交付的軟件質量低下而無法滿足預計要求。緩解措施采有模塊化方法設計軟件結構，并確保設計質量，使外包的部分盡可能獨立，需求穩(wěn)定，接口明確；確定一名專門的外包負責人負責建立和管理外包；從技術手段、管理方法、歷史績效、價格等多方面綜合評價外包方的能力，從中選擇合格者簽約；在外包執(zhí)行過程中，跟蹤監(jiān)督外包方的開發(fā)（包括進度、質量、資源等），協(xié)商解決有關變更，定期進行階段評審；在外包結束時，按合同進行驗收測試，包括功能測試、性能測試、易用性測試、可靠性測試、可支持性測試和交付文檔檢查。4610）缺乏足夠的用戶參與現(xiàn)象用戶常常由于業(yè)務過忙或者對需求分析不夠重視，使得參與人員的數(shù)量、能力或時間不足，甚至選派新手作為用戶代表。開發(fā)人員也可能不重視用戶的參與后果項目充滿著需求誤解的