高級軟件工程

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

三維操作系統(tǒng)

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

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