軟件質(zhì)量保證體系1課件

1、1開發(fā)過程的質(zhì)量交付產(chǎn)品的質(zhì)量2軟件質(zhì)量控制方法：目標問題度量法 風險管理法 PDCA質(zhì)量控制法3軟件質(zhì)量控制的基本方法準備開發(fā)進行開發(fā)進行可維護性開發(fā)收集實際數(shù)據(jù)目標問題度量法4風險管理法 控制跟蹤 識別 計劃分析在風險轉(zhuǎn)化成問題前進行識別監(jiān)視風險情況，檢查對策的適應性進行控制，可以避免、弱化、承擔、轉(zhuǎn)移在風險分析的基礎(chǔ)上進行決策各部分加強對風險的溝通對風險的影響、發(fā)生機率進行分類風險管理模型5風險嚴重程度等級 6軟件質(zhì)量控制模型和技術(shù)軟件質(zhì)量控制模型軟件質(zhì)量控制模型要素分析軟件質(zhì)量控制特征和技術(shù)軟件質(zhì)量控制實施和跟蹤7軟件質(zhì)量控制模型8 PDCA質(zhì)量控制法 9軟件質(zhì)量控制特征和技術(shù) 文檔編

2、制控制規(guī)則 受控文檔清單 受控文檔的編制 受控文檔的批準 受控文檔的存儲與檢索結(jié)果方面的問題1011軟件質(zhì)量控制工具檢查表Pareto圖直方圖運行圖散布圖控制圖因果圖12檢查表13Pareto圖14直方圖15運行圖16散布圖17因果圖18軟件質(zhì)量保證體系SQA審計與評審SQA報告處理不符合問題實施19軟件開發(fā)各個階段 SQA 的目標 6-1需求分析：確?？蛻羲蟮南到y(tǒng)是可行的。確?？蛻糁付ǖ男枨蟠_實能夠滿足他的真正要求。避免開發(fā)者和客戶之間的誤解。向用戶提供為滿足他所提出的需求而實際構(gòu)建的適當軟件系統(tǒng)。20軟件規(guī)格說明：通過建立需求跟蹤文檔，確保規(guī)格說明書與系統(tǒng)需求保持一致。確保規(guī)格說明書能

3、適當?shù)馗倪M系統(tǒng)的靈活性、可維護性以及性能。確保已建立了測試策略。確保已建立了現(xiàn)實的開發(fā)進度表，包括預定的評審。確保已為系統(tǒng)設(shè)計了正式的變更規(guī)程。軟件開發(fā)各個階段 SQA 的目標 6-221軟件開發(fā)各個階段的 SQA 目標 6-3設(shè)計：確保已建立用于描述設(shè)計的標準，并且確保遵循這些標準。確保適當?shù)乜刂撇⒂梦臋n記錄對設(shè)計進行的變更。確保在系統(tǒng)設(shè)計組件已按照商定的準則得到批準之后才開始編碼。確保對設(shè)計的評審按照進度進行。22軟件開發(fā)各個階段的 SQA 目標 6-4編碼：確保代碼遵循已建立的風格、結(jié)構(gòu)和文檔標準。確保代碼經(jīng)過適當測試和集成，同時對編碼模塊的修改得到適當?shù)臉俗R。查看代碼編寫是否遵循既定的

4、進度。確保代碼評審按照進度進行。23軟件開發(fā)各個階段的 SQA 目標 6-5測試：確保測試計劃的建立和遵循。確保創(chuàng)建的測試計劃能夠滿足所有系統(tǒng)規(guī)格說明書的要求。確保經(jīng)過測試和返工后軟件與規(guī)格說明書保持一致。24軟件開發(fā)各個階段的 SQA 目標 6-6維護：確保代碼和文檔的一致性。確保對已建立的變更控制過程進行監(jiān)測，包括將變更集成到軟件的產(chǎn)品版本中的過程。確保對代碼的修改遵循編碼標準，并且要對其進行評審，不要破壞整個代碼結(jié)構(gòu)。25軟件質(zhì)量策劃一切為用戶著想、一切以預防為主、一切憑數(shù)據(jù)說話和一切按PDCA循環(huán)辦事; 發(fā)軔于質(zhì)量運動，但非簡單的質(zhì)量管理；實質(zhì)是文化變革，關(guān)鍵在建立實施框架。-26質(zhì)量

5、策劃的活動 設(shè)定質(zhì)量目標；識別顧客一一受目標影響的人；確定顧客需求；開發(fā)反映顧客需求的產(chǎn)品特征；開發(fā)能夠生產(chǎn)具有這種特征產(chǎn)品的過程；設(shè)定過程控制，并把由此得出的計劃轉(zhuǎn)換成為操作計劃。27質(zhì)量計劃質(zhì)量計劃的目標和要素軟件質(zhì)量計劃內(nèi)容軟件質(zhì)量計劃的制定原則制定質(zhì)量計劃的方法和規(guī)程28質(zhì)量計劃的目標企業(yè)最高層親自抓質(zhì)量體系 質(zhì)量方針要反映對顧客的承諾 文件化的操作規(guī)程 質(zhì)量計劃是為了滿足用戶的期望 質(zhì)量計劃是為了降低不良質(zhì)量的成本 質(zhì)量計劃是為了在軟件開發(fā)全過程中實施質(zhì)量保證 29質(zhì)量計劃的要素在組織上，如何建立、宣傳質(zhì)量方針管理上質(zhì)量文化的形成質(zhì)量風險和成本的分析如何用流程改進來實施質(zhì)量管理如何通

6、過方法和工具來提高質(zhì)量管理的有效性如何進行軟件評審來檢驗質(zhì)量管理的實施效果30軟件質(zhì)量計劃內(nèi)容計劃目標參考文獻管理文檔標準和約定復審、內(nèi)審或評審配置管理測試問題報告和改正活動工具、技術(shù)和方法媒體的控制供應商的控制記錄、收集、維護和保密培訓風險管理31軟件質(zhì)量計劃的制定原則制定正確的質(zhì)量方針，缺陷預防為主的質(zhì)量管理思想始終以客戶的需求為焦點質(zhì)量計劃應得到管理層的認可和承諾控制所有過程的質(zhì)量。選擇合適的質(zhì)量標準持續(xù)的質(zhì)量改進，定期評價質(zhì)量體系 32制定質(zhì)量計劃的方法和規(guī)程產(chǎn)品介紹：說明產(chǎn)品、產(chǎn)品的意向市場及對產(chǎn)品性質(zhì)的預期。軟件計劃：包括產(chǎn)品確切的發(fā)布日期、產(chǎn)品責任及產(chǎn)品的銷售和售后服務(wù)計劃。過程

7、描述：產(chǎn)品的開發(fā)和管理中應該采用開發(fā)和售后服務(wù)質(zhì)量過程質(zhì)量目標：包括鑒定和驗證產(chǎn)品的關(guān)鍵質(zhì)量屬性。風險和風險管理：說明影響產(chǎn)品質(zhì)量的主要風險和這些風險的應對措施33制定質(zhì)量計劃的三部曲34為什么需要評審從成本上來衡量 缺陷發(fā)現(xiàn)得越晚糾正費用越高，而軟件評審的重要目的就是通過軟件評審盡早的產(chǎn)品中的缺陷，減少大量的后期返工。 35為什么需要評審從技術(shù)上來衡量 前一階段的錯誤自然會導致后一階段的工作結(jié)果中有相應的錯誤，而且錯誤會逐漸累積，越來越多。36軟件評審的角色和職能 協(xié)調(diào)人作者評審員用戶代表質(zhì)量保證代表 37評審的內(nèi)容管理評審技術(shù)評審文檔評審過程評審38管理評審 “由最高管理者就質(zhì)量方針和目標

8、，對質(zhì)量體系的現(xiàn)狀和適應性進行正式評價。” 39管理評審 質(zhì)量管理體系運行狀況 內(nèi)、外部審核結(jié)果 改進、預防和糾正措施的狀況 上次管理評審提出的改進措施實施情況及驗證信息管理評審 質(zhì)量體系的總體評價 質(zhì)量管理體系及其過程的改進 產(chǎn)品是否符合要求的評價，有關(guān)產(chǎn)品的改進 新資源的需求的決定和措施 輸入輸出對質(zhì)量體系進行回顧和總結(jié)并確保其適宜性、有效性和充分性 40技術(shù)評審 評審的目的 評審的內(nèi)容 評審檢查單 其他必需文檔技術(shù)評審技術(shù)評審報告會議的基本信息 存在的問題和建議措施 評審結(jié)論和意見問題跟蹤表技術(shù)評審問答記錄 輸入輸出41文檔評審1）正確性2）完整性3）一致性4）有效性5）易測性6）模塊化

9、-系統(tǒng)和文檔描述必須深入到模塊。模塊化指的是模塊的獨立性7）清晰性8）可行性9）可靠性10）可追溯性42過程評審過程評審的目的：評估主要的質(zhì)量保證流程考慮如何處理/解決評審過程中發(fā)現(xiàn)的不符合問題總結(jié)和共享好的經(jīng)驗指出需要進一步完善和改進的地方評審技術(shù)后，評審小組需要提交一份評審報告，其中包括：評審記錄評審后，對現(xiàn)有流程的說明和注釋評審小組的建議 43過程評審過程評審流程44評審的方法和技術(shù)評審的方法評審的技術(shù)45評審的方法臨時評審（Ad hoc review）輪查（Pass-round）走查（Walkthrough）小組評審（Group Review）審查（Inspection）最不正式最正式

10、臨時評審輪查 走查小組評審 審查46評審的方法審查、小組評審和走查異同點比較表 角色/職責審查小組評審走查主持者評審組長評審組長或作者作者材料陳述者評審者評審組長作者記錄員是是可能專門的評審角色是是否檢查表是是否問題跟蹤和分析是可能否產(chǎn)品評估是是否評審方法計劃準備會議修正確認審查有有有有有小組評審有有有有有走查是無有有無47評審的方法如何選擇正確的評審方法？選擇評審方法最有效的標準是：“對于最可能產(chǎn)生風險的工作成果，要采用最正式的評審方法?！?例如：核心代碼的失效也會帶來很嚴重的后果，所以也應該采用審查或小組評審的方法進行評審，而一般的代碼，則可以采用臨時評審、同桌評審等比較隨意的評審方法。

11、48評審的技術(shù)缺陷檢查表它列出了容易出現(xiàn)的典型錯誤，是評審的一個重要組成部分。 規(guī)則集類似于缺陷檢查表，通常是業(yè)界通用的規(guī)范或者企業(yè)自定義的各種規(guī)則的集合。 評審工具的使用合理的利用工具，如NASA開發(fā)的ARM（自動需求度量） 從不同角色理解不同的角色對產(chǎn)品/文檔的理解是不一樣的。 場景按照用戶使用場景對產(chǎn)品/文檔進行評審。 49準備評審會議評審計劃組建評審組3. 準備評審材料4. 發(fā)送審查包5. 制定活動進程表 各個階段的評審計劃的內(nèi)容包括：各個階段的評審時間、評審方式、評審組成員等。 SQA在其提交的質(zhì)量保證計劃中，應根據(jù)各個階段的評審計劃，制定相應的評審檢查點。50準備評審會議2. 組建

12、評審組 項目組提出評審組長和評審組成員名單的建議，質(zhì)量組根據(jù)項目組的建議，與相關(guān)部門或人員（如外項負責人）進行協(xié)商確定。 選定評審組長對評審來說是非常重要的，評審組長需要和作者一起，策劃和組織整個評審活動。 51準備評審會議3. 準備評審材料 基礎(chǔ)性和早期的文檔，如需求說明和原型等 與重大決策有關(guān)的文檔，如體系結(jié)構(gòu)模型 對如何做沒有把握的部分，如一些挑戰(zhàn)性模塊，他們實現(xiàn)了不熟悉的或復雜的算法，或涉及復雜的商業(yè)規(guī)則等 將不斷被重復使用的部件52準備評審會議4. 發(fā)送審查包 將被審查的可交付產(chǎn)品/文檔，其中指明了需要審查的部分 定義了可交付產(chǎn)品的前期文檔 相關(guān)標準或其他參考文檔 參與者需要的所有表

13、格 有助于審查者發(fā)現(xiàn)缺陷的工具/文檔：如缺陷檢查表，相關(guān)規(guī)則等 用于驗證可交付產(chǎn)品的測試文檔53準備評審會議5. 制定活動進程表 評審會議之前，評審組長還需要制定相應的活動進度表，安排會議房間，并將活動、日期、次數(shù)和地點通知評審組成員 54召開評審會議評審的主要步驟：1）由評審員/作者進行演示或說明。 2）評審員會就不清楚或疑惑的地方與作者進行溝通。3）協(xié)調(diào)人或記錄員在會議過程中完成會議記錄。55召開評審會議評審結(jié)果：接受，評審內(nèi)容不存在大的缺陷，可以通過有條件接受，評審內(nèi)容不存在大的缺陷，修訂其中的一些小缺陷后，可以通過不能接受，評審內(nèi)容中有較多的缺陷，作者需要對這些缺陷進行修改，并在修改之后重新進行評審。評審未完成，由于某種原因，評審未能完成，還需要后續(xù)會議56召開評審會議評審中的注意事項：人身攻擊 無休止的爭論 偏離會議中心 鼓勵所有人發(fā)言 57跟蹤和分析評審結(jié)果評審結(jié)果的跟蹤評審結(jié)果為有條件接受評審結(jié)果為不接受 2. 評審結(jié)果的分析有效性效率和成本58如何實施成功的評審解決不成功評審的主觀因素：對所有的工程師進行評審的培訓，使評審深入人心預防個人沖突，盡量避免對作者有人身攻擊的工程師加入評審小組將評審活動加入到項目計劃中，并為評審分配足夠的資源收集以前的評審數(shù)據(jù)，了解哪一種評審