第第6章項目質(zhì)量管理章項目質(zhì)量管理B22021-9-4如何看待的項目的質(zhì)量？如何看待的項目的質(zhì)量？32021-9-4實例實例 曾經(jīng)對一個國際性的軟件公司作了一個調(diào)查，選擇了由質(zhì)量問題引起的10項額外工作，即“開發(fā)人員修正缺陷、測試人員驗證缺陷、返工、設(shè)計或代碼完成后的需求變化、不清楚或無效的缺陷報告、代碼完成后補充的測試用例、由于缺陷修復(fù)后所做的回歸測試、測試環(huán)境設(shè)置錯誤、產(chǎn)品發(fā)布后遺漏的缺陷驗證、為產(chǎn)品發(fā)布后遺漏的缺陷出補丁包等”，統(tǒng)計結(jié)果表明，由于質(zhì)量問題造成的成本（劣質(zhì)成本）竟高達45.86%45.86%，差不多占開發(fā)總成本的一半。 所以，軟件項目質(zhì)量管理，不僅有助于提高軟件產(chǎn)品質(zhì)量，而且有助于縮短開發(fā)周期，降低成本42021-9-4冰山一角冰山一角52021-9-4真理真理v產(chǎn)品質(zhì)量是生產(chǎn)出來的，不是檢驗出來的 。威廉戴明v現(xiàn)實：現(xiàn)實：很多軟件公司投入大量時間和精力來發(fā)現(xiàn)和修發(fā)現(xiàn)和修正正錯誤（需求、設(shè)計、實現(xiàn)），導(dǎo)致進度延期。少了些質(zhì)量管理理解專業(yè)程序員中，扔進垃圾代碼，因為錯誤無法交工而不斷修改，最終開發(fā)出較好代碼的故事62021-9-4v 軟件的質(zhì)量管理貫穿了整個軟件開發(fā)周期。v 質(zhì)量管理不僅確保項目最終交付的產(chǎn)品滿足質(zhì)量要求，而且要保證項目實施過程中階段性成果的質(zhì)量。也就是保證軟件需求分析、設(shè)計和代碼的質(zhì)量，包括各種文檔的質(zhì)量v 正如ISO8402所規(guī)定和倡導(dǎo)的：“質(zhì)量管理是指確定質(zhì)量方針、目標和職責，并通過質(zhì)量體系中的質(zhì)量策劃、質(zhì)量控制、質(zhì)量保證和質(zhì)量改進來使其實現(xiàn)的所有管理職能的全部活動?！?質(zhì)量管理質(zhì)量管理項目質(zhì)量管理質(zhì)量規(guī)劃（始）質(zhì)量規(guī)劃（始） .1 .1 輸入輸入 .1 事業(yè)環(huán)境因素事業(yè)環(huán)境因素 .2 組織過程資產(chǎn)組織過程資產(chǎn) .3 項目范圍說明書項目范圍說明書 .4 項目管理計劃項目管理計劃 .2 .2 工具和技術(shù)工具和技術(shù) .1 成本效益分析成本效益分析 .2 基準對照基準對照 .3 實驗設(shè)計實驗設(shè)計 .4 質(zhì)量成本質(zhì)量成本 .5 其他質(zhì)量計劃工具其他質(zhì)量計劃工具 .3 .3 輸出輸出 .1 質(zhì)量管理計劃質(zhì)量管理計劃 .2 質(zhì)量衡量指標質(zhì)量衡量指標 .3 質(zhì)量檢查表質(zhì)量檢查表 .4 過程改進計劃過程改進計劃 .5 質(zhì)量基準質(zhì)量基準 .6 項目管理計劃項目管理計劃 (更新更新) 執(zhí)行質(zhì)量保證執(zhí)行質(zhì)量保證（中）（中） .1 .1 輸入輸入 .1 質(zhì)量管理計劃質(zhì)量管理計劃 .2 質(zhì)量測量指標質(zhì)量測量指標 .3 過程改進計劃過程改進計劃 .4 工作績效信息工作績效信息 .5 批準的變更請求批準的變更請求 .6 質(zhì)量控制度量質(zhì)量控制度量 .7 實現(xiàn)的變更請求實現(xiàn)的變更請求 .8 實現(xiàn)的糾正措施實現(xiàn)的糾正措施 .9 實現(xiàn)的缺陷修復(fù)實現(xiàn)的缺陷修復(fù) .10 實現(xiàn)的預(yù)防措施實現(xiàn)的預(yù)防措施.2 .2 工具和技術(shù)工具和技術(shù) .1 質(zhì)量計劃工具和技術(shù)質(zhì)量計劃工具和技術(shù) .2 質(zhì)量審計質(zhì)量審計 .3 過程分析過程分析 .4 質(zhì)量控制工具和技術(shù)質(zhì)量控制工具和技術(shù).3 .3 輸出輸出 .1 請求的變更請求的變更 .2 推薦的糾正措施推薦的糾正措施 .3 組織過程資產(chǎn)組織過程資產(chǎn)(更新更新) .4 項目管理計劃項目管理計劃(更新更新) 執(zhí)行質(zhì)量控制執(zhí)行質(zhì)量控制（尾）（尾） .1 .1 輸入輸入 .1 質(zhì)量管理計劃質(zhì)量管理計劃 .2 質(zhì)量測量指標質(zhì)量測量指標 .3 質(zhì)量檢查表質(zhì)量檢查表 .4 組織過程資產(chǎn)組織過程資產(chǎn) .5 工作績效信息工作績效信息 .6 批準批準的變更請求的變更請求 .7 可交付成果可交付成果 .2 .2 工具和技術(shù)工具和技術(shù) .1 因果圖因果圖 .2 控制圖控制圖 .3 流程圖流程圖 .4 直方圖直方圖 .5 帕雷托帕雷托圖圖 .6 趨勢圖趨勢圖 .7 散點圖散點圖 .8 統(tǒng)計抽樣統(tǒng)計抽樣 .9 檢查檢查 .10 缺陷修復(fù)審查缺陷修復(fù)審查 .3 .3 輸出輸出.1 質(zhì)量控制度量質(zhì)量控制度量 .2 確認的缺陷修復(fù)確認的缺陷修復(fù).3 質(zhì)量基準質(zhì)量基準 (更新更新).4 推薦的糾正措施推薦的糾正措施 .5 推薦的預(yù)防措施推薦的預(yù)防措施 .6 請求的變更請求的變更 .7 推薦的缺陷修復(fù)推薦的缺陷修復(fù) .8 組織過程資產(chǎn)組織過程資產(chǎn) (更新更新).9 確認的可交付成果確認的可交付成果 .10 項目管理計劃項目管理計劃 (更新更新)82021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理92021-9-4質(zhì)量管理概論質(zhì)量管理概論v 不同的質(zhì)量管理方式：病入膏肓病入膏肓及早治療及早治療提前預(yù)防提前預(yù)防102021-9-46.1 質(zhì)量管理概述質(zhì)量管理概述v 軟件質(zhì)量控制軟件質(zhì)量控制 (SQC，Software Quality Control) 是科學(xué)地測量過程狀態(tài)的基本的方法。就象汽車表盤上的儀器，可以了解行駛中的轉(zhuǎn)速、速度、油量等。v 軟件質(zhì)量保證軟件質(zhì)量保證 (SQA，Software Quality Assurance) 則是過程和程序的參考與指南的集合。就像汽車中的用戶手冊。v 軟件質(zhì)量管理軟件質(zhì)量管理 (SQM，Software Quality Management) 才是操作的誓學(xué)，教你如何駕車，建立質(zhì)量文化和管理思想。 112021-9-4四種不同的質(zhì)量管理水平四種不同的質(zhì)量管理水平v 檢查檢查，通過檢驗保證產(chǎn)品的質(zhì)量，符合規(guī)格的軟件產(chǎn)品為合格品，不符合規(guī)格的產(chǎn)品為次品。只能判斷產(chǎn)品質(zhì)量，不檢驗工藝流程、設(shè)計、服務(wù)等，不能提高軟件質(zhì)量。相當于“軟件測試/質(zhì)量控制”;v 保證保證，質(zhì)量目標通過軟件開發(fā)部門來實現(xiàn)，制定質(zhì)量目標和質(zhì)量計劃，保證軟件開發(fā)流程軟件開發(fā)流程合理性、流暢性和穩(wěn)定性。相當于初期初期的“質(zhì)量保證”;v 預(yù)防預(yù)防，軟件質(zhì)量以預(yù)防為主，以過程管理為重，把質(zhì)量的保證工作重點放在過程管理上。從需求、設(shè)計開始就引入預(yù)防思想，相當于成熟成熟的“質(zhì)量保證”;v 完美完美，以客戶為中心，貫穿于軟件開發(fā)生存期過程，全員參與，追求卓越，相當于“全面軟件質(zhì)量管理”。 122021-9-4質(zhì)量管理質(zhì)量管理的支持的支持質(zhì)量管理質(zhì)量管理技術(shù)（開發(fā)技術(shù)成熟技術(shù)（開發(fā)技術(shù)成熟度、開發(fā)工具、自動度、開發(fā)工具、自動化測試水平）化測試水平）方法（開發(fā)模型、方法（開發(fā)模型、開發(fā)流程）開發(fā)流程）基礎(chǔ)設(shè)施（質(zhì)量文化、開發(fā)環(huán)境、基礎(chǔ)設(shè)施（質(zhì)量文化、開發(fā)環(huán)境、標準體系標準體系132021-9-4技術(shù)層次的質(zhì)量管理支持技術(shù)層次的質(zhì)量管理支持v 制定編程規(guī)范，有利于整體風格的統(tǒng)一、提高代碼可讀性、可維護性、可擴展性v 組織應(yīng)通過制定統(tǒng)一的模板來規(guī)范文檔，統(tǒng)一文檔內(nèi)容和風格v 實施覆蓋生命周期的軟件測試，包括單元、集成、系統(tǒng)測試，不僅要動態(tài)測試，也要靜態(tài)測試（需求分析、系統(tǒng)設(shè)計需要評審和驗證）v 采用統(tǒng)計方法（一般是量化的數(shù)理統(tǒng)計分析）揭示產(chǎn)品特征和軟件開發(fā)過程特征，發(fā)現(xiàn)各種不一致性問題142021-9-4基礎(chǔ)設(shè)施基礎(chǔ)設(shè)施152021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理162021-9-4組織保證組織保證管理層測試組SQA組SEPG組項目組172021-9-4組織保證（續(xù)）組織保證（續(xù)）v 管理組管理組：很強的“質(zhì)量第一”的意識，能制定有利于保證和提高質(zhì)量的正確策略和方針，在整個組織中營造良好的質(zhì)量文化。v SQASQA組組：從流程上對軟件質(zhì)量進行跟蹤、控制和改進。即監(jiān)督監(jiān)督項目按已經(jīng)定義的流程進行，并符合已定義的相關(guān)標準。如要求建立相關(guān)文檔、需求變更控制v 測試組測試組：負責對軟件產(chǎn)品進行全面的測試，包括需求評審、設(shè)計評審、功能和性能測試等，從中找出所存在的缺陷。測試組面向產(chǎn)品，進行事后檢查。v SEPGSEPG組組：軟件工程過程組，通常有軟件專家組成，領(lǐng)導(dǎo)和協(xié)調(diào)過程改進的小組。其主要任務(wù)是推動企業(yè)所應(yīng)用的過程的定義、維護和改進。類似于一個“立法”機構(gòu)182021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理192021-9-4質(zhì)量計劃概述質(zhì)量計劃概述v 質(zhì)量計劃：質(zhì)量計劃：進行項目質(zhì)量管理，實施項目質(zhì)量方針和目標的具體規(guī)劃。v 質(zhì)量計劃通常在組織的質(zhì)量方針指導(dǎo)下定義項目的質(zhì)量目標，描述項目質(zhì)量管理中所需的資源、職責分配，說明如何采用正確的流程和操作程序、質(zhì)量控制方法和評審技術(shù)來保證質(zhì)量。v 軟件質(zhì)量計劃需要覆蓋軟件開發(fā)和維護的整個生命周期，即需要對需求分析、設(shè)計、編碼、測試、部署提出質(zhì)量目標和要求，并就質(zhì)量控制內(nèi)容、方法和手段給出建議和指導(dǎo)。202021-9-46.3 質(zhì)量計劃質(zhì)量計劃6.3.1 質(zhì)量計劃的內(nèi)容6.3.2 質(zhì)量計劃制定的步驟6.3.3 如何制定有效的質(zhì)量計劃6.3.4 質(zhì)量計劃的實施和控制212021-9-46.3.1 質(zhì)量計劃的內(nèi)容質(zhì)量計劃的內(nèi)容v 目的和范圍v 參考的文件列表v 質(zhì)量目標，總體目標，分階段目標，分項目標v 質(zhì)量的任務(wù)，包括組織流程說明會，關(guān)鍵成果評審v 參與質(zhì)量管理的相關(guān)人員及其責任v 對一些關(guān)鍵文檔提出要求。如測試計劃，配置管理計劃v 重申適合項目的相關(guān)標準。如文檔模板標準，代碼編寫標準v 評審的流程和標準。如明確區(qū)分代碼評審和技術(shù)評審的不同點v 配置管理要求，如代碼版本控制、需求變更控制v 問題報告和處理系統(tǒng)v 采用的質(zhì)量控制工具、技術(shù)和方法等222021-9-4質(zhì)量計劃模板參照質(zhì)量計劃模板參照v 項目概述v 實施策略v 項目組織v 質(zhì)量保證對象分析及選擇v 質(zhì)量保證任務(wù)劃分v 實施計劃v 資源計劃v 記錄的收集、維護與保存樣例詳見樣例詳見P141232021-9-4質(zhì)量評審的內(nèi)容和手段質(zhì)量評審的內(nèi)容和手段v內(nèi)容內(nèi)容1.需求說明評審2.設(shè)計文檔評審3.測試計劃評審4.功能性審核（內(nèi)審）5.物理性審核（內(nèi)審）6.管理評審v手段手段內(nèi)審內(nèi)審：部門內(nèi)部審查自己的工作，或者由一個獨立部門審查其他各部門的工作，以檢查組織內(nèi)部是否遵守已有的模板、規(guī)則和流程等復(fù)審復(fù)審：在軟件開發(fā)生命周期每個階段結(jié)束之前，都正式用結(jié)束標準對該階段的階段性成果進行嚴格的技術(shù)審查。242021-9-4質(zhì)量計劃制定的步驟（質(zhì)量計劃制定的步驟（1）1.了解項目的基本概況，收集項目有關(guān)資料了解項目的基本概況，收集項目有關(guān)資料v重點了解項目的目標、用戶需求和項目的實施范圍2. 確定項目的質(zhì)量目標確定項目的質(zhì)量目標 v先根據(jù)項目總體目標和用戶需求確定項目的質(zhì)量總目標v再根據(jù)項目組成和劃分來分解項目質(zhì)量目標v然后建立各個具體的質(zhì)量目標3. 確定圍繞質(zhì)量目標的工作任務(wù)確定圍繞質(zhì)量目標的工作任務(wù) v評審、跟蹤、統(tǒng)計分析等4. 明確項目質(zhì)量管理組織機構(gòu)明確項目質(zhì)量管理組織機構(gòu) v配備各級質(zhì)量管理人員、設(shè)備資源v確定質(zhì)量管理人員的角色和責任，建立質(zhì)量管理機構(gòu)252021-9-4質(zhì)量計劃制定的步驟（質(zhì)量計劃制定的步驟（2）-項目質(zhì)量責項目質(zhì)量責任表任表角色質(zhì)量責任項目經(jīng)理協(xié)助質(zhì)量保證人員、測試組長的工作。進行全程的質(zhì)量跟蹤，報告質(zhì)量問題，負責質(zhì)量改進措施的實施質(zhì)量保證人員對開發(fā)和測試過程進行質(zhì)量控制，制定質(zhì)量計劃并負責實施、監(jiān)控，組織所要求的各類評審會議等系統(tǒng)分析員 負責需求評審的組織和實施，保證需求定義符合相關(guān)的規(guī)范架構(gòu)師開發(fā)組負責人，負責設(shè)計的評審編程人員負責詳細設(shè)計、編程、單元測試測試組組長 參與需求、設(shè)計評審等會議。制定測試計劃和測試用例的評審，執(zhí)行測試的質(zhì)量跟蹤測試人員編寫測試用例，并參與評審文檔編寫人員審查相關(guān)文檔是否采用了最新的模板，是否符合文檔規(guī)范的要求262021-9-4質(zhì)量計劃制定的步驟（質(zhì)量計劃制定的步驟（3）5. 制定項目質(zhì)量控制程序制定項目質(zhì)量控制程序 v項目質(zhì)量控制工作程序v初始的檢查試驗和標識程序v項目實施過程中的質(zhì)量檢查程序v不合格項目產(chǎn)品的控制程序v各類項目實施質(zhì)量記錄的控制程序和交驗程序6. 項目質(zhì)量計劃的評審項目質(zhì)量計劃的評審 v如果項目規(guī)模較大，可以按照子項目，或根據(jù)項目進度分階段編制和評審項目計劃272021-9-46.3.3 如何制定有效的質(zhì)量計劃如何制定有效的質(zhì)量計劃質(zhì)量計劃有效性體現(xiàn)在：質(zhì)量計劃有效性體現(xiàn)在：1.項目質(zhì)量計劃要保證項目按計劃期限完成2.要處理好項目質(zhì)量計劃與其他計劃之間的關(guān)系保證項目質(zhì)量計劃有效性的幾種方法：1.利益利益/成本分析成本分析。效益與成本之比盡可能的大。利益：減少重復(fù)性工作（避免返工），增加投資者的滿意度成本：項目質(zhì)量管理活動的付出2.基準基準：以其他同類歷史項目的質(zhì)量計劃進行比較，為改進項目實施過程提供思路和可參考的標準。3.流程圖：流程圖：因果圖：主要用來尋找引起質(zhì)量問題的根本原因系統(tǒng)流程圖或處理流程圖：可以幫助找出解決所遇質(zhì)量問題的相關(guān)方法4.試驗設(shè)計。試驗設(shè)計。嘗試找出最影響質(zhì)量的因素、驗證質(zhì)量管理的合理性282021-9-46.3.4 質(zhì)量計劃的實施和控制前言質(zhì)量計劃的實施和控制前言v 質(zhì)量計劃主要是獲得產(chǎn)生質(zhì)量缺陷的原因，從而減少軟件缺陷或避免將來犯類似錯誤v 通過設(shè)置檢查點、驗證點，對階段性成果進行評審或完成質(zhì)量評估，以確定項目階段性成果是否達到所設(shè)定的質(zhì)量標準。v 項目收尾階段的質(zhì)量控制項目收尾階段的質(zhì)量控制是一個非常重要而又容易忽視的內(nèi)容。它需要檢查項目文件資料的完備性，包括評審會議記錄、測試報告等。同時進行項目總結(jié)292021-9-46.3.4 質(zhì)量計劃的實施和控制（續(xù)）質(zhì)量計劃的實施和控制（續(xù)）v加強對質(zhì)量計劃執(zhí)行情況的檢查，及時發(fā)現(xiàn)問題v在項目總體目標不變的前提下，應(yīng)根據(jù)原質(zhì)量計劃和實際情況進行比較分析，找出問題產(chǎn)生的根本原因v針對原因，制定出相應(yīng)的技術(shù)保證措施，對原計劃做出適當?shù)恼{(diào)整，以確保項目質(zhì)量總目標的圓滿實現(xiàn)。302021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理312021-9-46.4 軟件評審方法和過程軟件評審方法和過程6.4.1 軟件評審的方法和技術(shù)軟件評審的方法和技術(shù)6.4.2 角色和責任角色和責任6.4.3 軟件評審過程軟件評審過程6.4.4 如何有效地組織評審如何有效地組織評審322021-9-4軟件評審軟件評審v 不管你有沒有發(fā)現(xiàn)他們，缺陷總是存在，問題只是你最終發(fā)現(xiàn)它們時，需要多少糾正成本。評審的投入把質(zhì)量成本從評審的投入把質(zhì)量成本從昂貴的、后期返工轉(zhuǎn)變?yōu)樵缙诘娜毕莅l(fā)現(xiàn)昂貴的、后期返工轉(zhuǎn)變?yōu)樵缙诘娜毕莅l(fā)現(xiàn)。卡爾威格 332021-9-4軟件評審的方法軟件評審的方法v臨時評審臨時評審（Ad hoc review）：自發(fā)使用v輪查輪查（Passroud）：郵件分發(fā)審查，異步進行v互為復(fù)審互為復(fù)審：兩個人工作內(nèi)容和技術(shù)比較接近，涉及人員很少，復(fù)審效率較高，如極限編程v走查走查（Walkthrough）：對評審對象要從頭到尾檢查一遍v審查審查（Inspection）：系統(tǒng)化、嚴密的集體評審方法最不正式最不正式最正式最正式臨時評審臨時評審輪查輪查互為復(fù)審互為復(fù)審走查走查 會議審查會議審查342021-9-4軟件評審方法（續(xù)）軟件評審方法（續(xù)）v 在軟件開發(fā)過程中，各種評審技術(shù)交替使用，其原則：1. 在不同的開發(fā)階段和不同的場合選擇適合的評審方法需求和設(shè)計評審初稿：輪查需求和設(shè)計最終定稿之前：評審會議代碼評審：互為評審、自發(fā)采用“臨時評審”2. 對最可能產(chǎn)生較大風險的工作成果，要采用最正式的評審方法需求分析報告：走查或者會議評審核心代碼：走查或者會議評審352021-9-4軟件評審技術(shù)軟件評審技術(shù)v檢查表技術(shù)：檢查表技術(shù)：簡單、提高評審效率、改進評審質(zhì)量。例如缺陷檢查表列出容易出現(xiàn)的典型錯誤，幫助找出缺陷，排除隱患v場景分析技術(shù)場景分析技術(shù)：更能發(fā)現(xiàn)錯誤和問題，耗時多。多用于需求文檔評審，發(fā)現(xiàn)遺漏和多余的需求v工具：工具：提高效率，如IBM的RRP、NASA的ARM，對導(dǎo)入的文檔統(tǒng)計分析，找出各種詞語的出現(xiàn)概率，對完整性和二義性進行分析362021-9-46.4.2 評審過程中的角色和責任評審過程中的角色和責任v小組組長v作者v讀者v記錄者v評審員v審核者v協(xié)調(diào)者372021-9-46.4.3 軟件評審過程軟件評審過程（1）382021-9-4軟件評審過程軟件評審過程（2）v 計劃 確定被評審對象 確定期望達到的評審目標 計劃選用的評審方法v 會議準備 確定評審組長：經(jīng)驗豐富、技術(shù)能力強、工作認真負責、不能和作者有密切關(guān)系（保持評審客觀性） 選定評審材料，找出哪些是必須評審的 分發(fā)評審材料 制定相應(yīng)的活動進度表，提前2-3天通知小組成員392021-9-4軟件評審過程軟件評審過程（3）召開會議：召開會議：1.簡要說明待審查內(nèi)容、重申會議目標2.詳細說明評審材料，了解各評審員對材料的了解是否一致3.如理解不一致，容易發(fā)現(xiàn)問題（二義性、遺漏、錯誤假設(shè)），從而找出缺陷4.記錄問題和缺陷5.記錄員向小組重述記錄的缺陷6.評審決議座次圖座次圖主持人作者記錄員列席人員內(nèi)審員技術(shù)專業(yè)人員402021-9-4軟件評審過程軟件評審過程（4）v評審決議的幾種情況 接受 有條件接受：修訂其中的一些小缺陷后通過 不能接受 評審未完成v問題跟蹤（返工） 驗證作者是否恰當?shù)亟鉀Q了評審會上所列出的問題 考慮是否需要再次召開評審會議412021-9-4評審評審注意事項注意事項v 明確自己的角色和責任；v 熟悉評審內(nèi)容，為評審做好準備，做細做到位；v 關(guān)注問題，針對問題闡述觀點，而不是對人；v 可以分別討論主要的問題和次要的問題；v 在會議前或者會議后可以就存在的問題提出自己的建設(shè)性的意見；v 提高溝通能力，采取適當?shù)?、靈活的表述方式；v 對發(fā)現(xiàn)的問題，要跟蹤到底。422021-9-46.4.4 如何有效地組織評審如何有效地組織評審什么叫有效評審：什么叫有效評審： 盡可能、盡早地發(fā)現(xiàn)問題和缺陷 高效、省時、省力實施要點：實施要點： 把握好流程和評審目標 認真、仔細地閱讀評審材料，不斷思考 善于提問 充分溝通 一切圍繞用戶需求進行 。用戶？用戶的操作習(xí)慣？用戶的業(yè)務(wù)流程？應(yīng)用場景和操作模式432021-9-4評審評審組織方法組織方法v分層評審方法分層評審方法 （高層次、低層次）1.先總體后細節(jié)先總體后細節(jié)，避免過早陷入細節(jié)，只見樹木，不見森林2.高層次評審高層次評審：主要評審產(chǎn)品是否滿足客戶的需求和期望，是否具有合理的功能層次性和完備性，能否滿足客戶各個方面的需求3.低層次評審低層次評審：逐字逐行地評審文檔的各項描述，包括文字、圖表，要求準確、完整、清晰。比如，需要較高的性能、多數(shù)情況下支持.vWeb頁的刷新響應(yīng)時間不超過3秒（不專業(yè)、不明確）v每一個頁面訪問的響應(yīng)時間不超過3秒442021-9-4評審評審組織方法（續(xù)）組織方法（續(xù)）v分類評審方法分類評審方法 （分業(yè)務(wù)需求、功能需求、非功能需求、用戶操作性需求等 ）業(yè)務(wù)需求業(yè)務(wù)需求：最基本的需求、核心需求。用戶的高層代表關(guān)注。資深人員（測試經(jīng)理）參加評審。功能性需求功能性需求：用戶的中層人員關(guān)注。用戶的中層人員和各個功能模塊負責人參加評審。操作性需求操作性需求：用戶的操作人員關(guān)注。具體操作人員和測試工程師參加評審v分階段評審方法，比如：分階段評審方法，比如：目標性需求形成時，系統(tǒng)功能框架形成時，當功能細化成幾個部分后，對每個部分分別進行， 對關(guān)鍵的非功能性進行單獨評審對整體的需求進行全面評審452021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理462021-9-46.5 缺陷預(yù)防和跟蹤分析缺陷預(yù)防和跟蹤分析6.5.1 缺陷預(yù)防缺陷預(yù)防6.5.2 缺陷分析缺陷分析6.5.3 魚骨圖魚骨圖 軟件缺陷不僅僅局限于程序功能的問題，任何軟件缺陷不僅僅局限于程序功能的問題，任何與用戶需求不符合的地方都是缺陷。需求說明、設(shè)與用戶需求不符合的地方都是缺陷。需求說明、設(shè)計文檔、測試用例等文檔中也同樣存在缺陷計文檔、測試用例等文檔中也同樣存在缺陷472021-9-46.5.1 缺陷預(yù)防缺陷預(yù)防-whyv 質(zhì)量大師克勞士比提倡“零缺陷管理”，在傳統(tǒng)工業(yè)工程中深受歡迎。零缺陷管理的中心思想：第一次就把事情做正確第一次就把事情做正確，從而消除劣質(zhì)成本，從而消除劣質(zhì)成本。v 項目管理既要保證質(zhì)量又要降低成本，最佳結(jié)合點最佳結(jié)合點就是要求每一個人“第一次把事情做好”v 軟件產(chǎn)品的質(zhì)量是做出來的，不是測試出來的。 上千人的印度軟件公司，只有5-6個SQA，無測試團隊，軟件質(zhì)量依舊很好。482021-9-46.5.1 缺陷預(yù)防缺陷預(yù)防-howv從流程上加強控制 建立和規(guī)范工作流程，加強評審 過程改進v采用有效的工作方法 代碼評審 單元測試v提高個人的技術(shù)水平 自我學(xué)習(xí)和提高v延伸：測試驅(qū)動開發(fā)TDD492021-9-46.5.2 缺陷分析缺陷分析（1）v 缺陷分析：缺陷分析： 將軟件開發(fā)、運行過程中產(chǎn)生的缺陷進行必要的收集，對缺陷的信息進行分類和匯總統(tǒng)計v 作用作用：通過缺陷分析，可以發(fā)現(xiàn)各種類型缺陷發(fā)生的概率，掌握缺陷集中的區(qū)域，明確缺陷的發(fā)展趨勢，了解缺陷產(chǎn)生的主要原因。以便有針對性地提出遏制缺陷發(fā)生的措施，降低缺陷數(shù)量。v 缺陷收集工具缺陷收集工具：IBM的RTC、MantisBT、Bugfree、Bugzilla502021-9-46.5.2 缺陷分析缺陷分析（2）v缺陷趨勢分析缺陷趨勢分析 （實時、累積）v缺陷分布分析缺陷分布分析 （如缺陷產(chǎn)生的原因、階段、來源）512021-9-4趨勢趨勢分析趨勢趨勢分析v 缺陷趨勢分析缺陷趨勢分析 （實時、累積）：針對缺陷數(shù)目隨時間而不斷變化的趨勢進行分析，了解缺陷的發(fā)現(xiàn)或修正過程是否符合期望的規(guī)律性，是否出現(xiàn)異?，F(xiàn)象。v 需要統(tǒng)計每天的缺陷發(fā)現(xiàn)和修訂情況。522021-9-4缺陷發(fā)展趨勢分析示例缺陷發(fā)展趨勢分析示例532021-9-4缺陷分布分析及示例缺陷分布分析及示例不同模塊的缺陷分布圖不同模塊的缺陷分布圖 不同階段的缺陷分布圖不同階段的缺陷分布圖 v 缺陷分布分析缺陷分布分析 ：一種橫向分析，即分析缺陷在功能模塊、缺陷類型、缺陷產(chǎn)生原因等不同方面的分布情況。542021-9-4分布分析示例分布分析示例 2不同級別的缺陷分布圖不同級別的缺陷分布圖 552021-9-46.5.3 魚骨圖魚骨圖v 可以更全面地探討各種類別的原因v 鼓勵通過自由討論發(fā)揮大家的創(chuàng)造性 v 提供問題與各類原因之間關(guān)系的直觀表示 魚骨圖魚骨圖，也叫因果分析圖，它是分析影響事物質(zhì)量形成的諸要素間因果關(guān)系的一種分析圖。因為其形狀像魚骨，俗稱魚骨圖。562021-9-4魚骨圖的應(yīng)用過程魚骨圖的應(yīng)用過程 魚骨圖分析法要完成從主刺到小刺的思維和分析過程魚骨圖分析法要完成從主刺到小刺的思維和分析過程，一般分三步：1. 確定問題：或?qū)嶋H問題，或潛在問題2. 找出問題的主要原因：可以采用5M方法Manpower（人力）：造成問題產(chǎn)生的人為因素是什么Machinery（機械）：軟硬件條件對事件的影響Materials（物料）：基礎(chǔ)的準備以及原材料Methods（方法）：與事件相關(guān)的方式與方法是否正確有效Mother-nature（環(huán)境）：內(nèi)、外部環(huán)境因素的影響3. 根據(jù)問題類別，確定細節(jié)原因572021-9-4示例示例582021-9-4工具工具XMind 2008 Pro592021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量質(zhì)量度量6.7 過程質(zhì)量管理602021-9-46.6 質(zhì)量質(zhì)量度量度量6.6.1 度量要素度量要素6.6.2 基于缺陷的質(zhì)量度量基于缺陷的質(zhì)量度量612021-9-4質(zhì)量度量的作用質(zhì)量度量的作用1. 有效的溝通和改進可見性。 2. 盡早的發(fā)現(xiàn)和更正問題。 3. 作出關(guān)鍵的權(quán)衡。 4. 跟蹤特定的項目目標。按時？質(zhì)量改進？ 5. 管理風險。風險降低了嗎？ 6. 有助于決策。 7. 計劃未來的項目。做為歷史數(shù)據(jù)！ 622021-9-46.6.1 度量要素度量要素v 項目度量項目度量：項目的規(guī)模、成本、工作量、進度、生產(chǎn)力、風險、顧客滿意度v 產(chǎn)品度量產(chǎn)品度量：以質(zhì)量度量為中心，包括功能性、可靠性、易用性、可維護性、可移植性v 過程度量過程度量：成熟度、管理、生命周期、生產(chǎn)率等 632021-9-4度量的表示方法度量的表示方法v 數(shù)據(jù)v 圖表v 模型：為了某種特定目的而對研究對象所做的一種簡化的一種簡化的描述或者模擬描述或者模擬?？梢詭椭吻逶亻g的相互關(guān)系，識別關(guān)鍵元素，使得復(fù)雜信息簡單易懂。642021-9-46.6.2 基于缺陷的基于缺陷的質(zhì)量度量質(zhì)量度量-代碼質(zhì)量代碼質(zhì)量v 代碼質(zhì)量代碼質(zhì)量 BTPi :測試過程中發(fā)現(xiàn)的各種級別缺陷的數(shù)目。 BFi :產(chǎn)品發(fā)布之后發(fā)現(xiàn)的各種級別缺陷的數(shù)目。 Wli :各個缺陷的權(quán)重系數(shù)，詳見P159頁的表6-6 WTP：測試過程中發(fā)現(xiàn)的缺陷的權(quán)重（測試小組內(nèi)、外發(fā)現(xiàn)的缺陷） WF 產(chǎn)品發(fā)布之后的缺陷的權(quán)重 KCSI：新增加的和修改的千行代碼數(shù) 代碼質(zhì)量指標：這個值越低，說明發(fā)現(xiàn)的缺陷越少或者嚴重性越低，同時說明代碼質(zhì)量越高KCSIWTPFW+代碼質(zhì)量代碼質(zhì)量=652021-9-46.6.2 基于缺陷的基于缺陷的質(zhì)量度量質(zhì)量度量產(chǎn)品質(zhì)量產(chǎn)品質(zhì)量KCSIFWv 產(chǎn)品質(zhì)量產(chǎn)品質(zhì)量 WF 產(chǎn)品發(fā)布之后的缺陷的權(quán)重 KCSI：新增加的和修改的千行代碼數(shù) 指標含義：指標含義：這個指標值越低，說明遺留給客戶的缺陷越少或者嚴重性越低，同時說明產(chǎn)品發(fā)布的質(zhì)量越高。產(chǎn)品質(zhì)量產(chǎn)品質(zhì)量=662021-9-46.6.2 基于缺陷的基于缺陷的質(zhì)量度量質(zhì)量度量測試有效性測試有效性%100*)W+(FTPTWWv 測試有效性測試有效性 WT：整個產(chǎn)品中由測試小組發(fā)現(xiàn)的所有缺陷的權(quán)重，不僅包含了測試小組在測試階段發(fā)現(xiàn)的缺陷，也包括產(chǎn)品發(fā)布之后由測試小組發(fā)現(xiàn)的缺陷 WTP：測試過程中發(fā)現(xiàn)的缺陷的權(quán)重（測試小組內(nèi)、外發(fā)現(xiàn)的缺陷） WF 產(chǎn)品發(fā)布之后的缺陷的權(quán)重 指標含義：指標含義：這個指標值越高，約接近100%，說明測試小組的有效性（效率）越高。做為高水平的測試團隊，可以達到90-95%測試有效性測試有效性=672021-9-4第第6章項目質(zhì)量管理章項目質(zhì)量管理6.1 質(zhì)量管理概述6.2 項目質(zhì)量的組織保證6.3 質(zhì)量計劃6.4 軟件評審方法和過程6.5 缺陷預(yù)防和跟蹤分析6.6 質(zhì)量度量6.7 過程質(zhì)量管理過程質(zhì)量管理682021-9-46.7 過程質(zhì)量管理過程質(zhì)量管理6.7.1 過程質(zhì)量度量6.7.2 缺陷移除和預(yù)防692021-9-46.7.1 過程質(zhì)量度量過程質(zhì)量度量v 產(chǎn)品的質(zhì)量在一定程度上依賴于過程的質(zhì)量。v 軟件過程軟件過程質(zhì)量的度量：的度量：對軟件開發(fā)過程中各個方面質(zhì)量指標進行度量，目的在于預(yù)測過程的未來性能，減少過程結(jié)果的偏差，對軟件過程的行為進行目標管理，為過程控制、過程評價、持續(xù)改善建立量化管理奠定基礎(chǔ)v 過程質(zhì)量度量的指標指標有： 過程缺陷密度 整體缺陷清除率 階段性缺陷清除率 缺陷到達模式702021-9-4過程質(zhì)量度量過程質(zhì)量度量過程缺陷密度過程缺陷密度v過程缺陷密度（Density In Process Faults，DIPF）：用來判定過程產(chǎn)品的質(zhì)量，以及檢驗過程的執(zhí)行程度。vDn：某階段或整個項目被發(fā)現(xiàn)的缺陷數(shù)vSp：被測試的軟件產(chǎn)品規(guī)模數(shù)（如代碼行數(shù)、功能點數(shù)、對象數(shù)等）v當DIPF過低時，應(yīng)考慮兩種情況：1.軟件產(chǎn)品質(zhì)量很好，缺陷很少2.方法或者能力不到位，不能發(fā)現(xiàn)產(chǎn)品中的某部分缺陷DIPF = Dn / Sp 712021-9-4過程質(zhì)量度量過程質(zhì)量度量整體缺陷清除率整體缺陷清除率v 缺陷被清除的程度缺陷被清除的程度能反映出項目組在質(zhì)量上的工作表現(xiàn)，也能反映待發(fā)布的產(chǎn)品質(zhì)量。v 如果開發(fā)中大量的嚴重缺陷未被清除，可能阻止測試進行，也必然影響軟件過程的質(zhì)量和性能v 缺陷清除率缺陷清除率（Defect Removal Efficiency，DRE）度量缺陷清除的程度。產(chǎn)品中潛伏的缺陷數(shù)開發(fā)階段清除的缺陷數(shù)100722021-9-4過程質(zhì)量度量過程質(zhì)量度量整體缺陷清除率（續(xù)）整體缺陷清除率（續(xù)）假定假定v F：軟件規(guī)模的功能點數(shù)v D1：軟件開發(fā)過程中發(fā)現(xiàn)的所有缺陷數(shù)v D2：軟件發(fā)布后發(fā)現(xiàn)的缺陷數(shù)v D：發(fā)現(xiàn)的總?cè)毕輸?shù)。D=D1+D2。則則v 質(zhì)量=D2/Fv 缺陷注入率=D/Fv 整體缺陷清除率=D1/Dv 例如例如：某系統(tǒng)有100個功能點，開發(fā)中發(fā)現(xiàn)了20個缺陷，提交后又發(fā)現(xiàn)了3個錯誤。v 解解：D1=20，D2=3，D=D1+D2=23。 質(zhì)量=D2/F=3/100 缺陷注入率=D/F=23/100 整體缺陷清除率=D1/D=3/23業(yè)界平均水平為80%高水平軟件公司可達到95%732021-9-4過程質(zhì)量度量過程質(zhì)量度量階段性缺陷清除率階段性缺陷清除率v 清除軟件缺陷的難易程度在各個階段不同。比如需求分析問題、設(shè)計錯誤的修改相對困難些v 引入階段性缺陷清除率，細化DRE指標。過程中注入的缺陷數(shù)陷數(shù)（該階段）開發(fā)該階段入口處存在的缺）排除的缺陷數(shù)（該階段100742021-9-4過程質(zhì)量度量過程質(zhì)量度量缺陷到達模式缺陷到達模式v 問題：問題：產(chǎn)品的缺陷密度或者測試階段的缺陷率是概括性指標。兩個正在開發(fā)的軟件產(chǎn)品，其缺陷密度是一樣的，但其質(zhì)量差異可能較大，一個發(fā)布前的缺陷多，而另一個發(fā)布后的缺陷多。如何描述這種差異呢？v 缺陷到達模式缺陷到達模式可以提供這種過程信息。模式一表明：測試團隊越成熟，峰值到達得越早，糾正成本越低，軟件質(zhì)量越高。752021-9-4過程質(zhì)量度量過程質(zhì)量度量缺陷到達模式（續(xù)）缺陷到達模式（續(xù)）缺陷到達模式的作用：缺陷到達模式的作用：1. 可以用于整個軟件開發(fā)周期或者某個特定的開發(fā)階段（單元測試階段、系統(tǒng)測試階段等）；2. 可以擴展到修正的缺陷、關(guān)閉的缺陷，可以獲取有關(guān)開發(fā)人員工作效率分析、缺陷修正進程分析、質(zhì)量進程分析。762021-9-4過程質(zhì)量度量過程質(zhì)量度量缺陷發(fā)現(xiàn)率缺陷發(fā)現(xiàn)率v缺陷發(fā)現(xiàn)率 bug/KLOCKLOC是指千行代碼，而bug/KLOC的意思是每千行代碼平均產(chǎn)生的缺陷數(shù)量 。CMM1CMM111.9511.95CMM2CMM25.525.52CMM3CMM32.392.39CMM4CMM40.920.92CMM5CMM50.320.32772021-9-46.7.2 缺陷移除和預(yù)防方法缺陷移除和預(yù)防方法v 經(jīng)常查看缺陷數(shù)據(jù)并更新缺陷檢查表。經(jīng)常查看缺陷數(shù)據(jù)并更新缺陷檢查表。當發(fā)現(xiàn)什么地方做得好就保持，發(fā)現(xiàn)什么地方做得不好就反思如何改進并更新檢查表。不斷地，檢查表就變成了個人經(jīng)驗的總結(jié)。v 數(shù)據(jù)記錄和分析數(shù)據(jù)記錄和分析v 有效的設(shè)計。有效的設(shè)計。v 更完善徹底的設(shè)計更完善徹底的設(shè)計782021-9-4本章小結(jié)本章小結(jié)v 項目質(zhì)量保證的組織架構(gòu)（測試組、管理層、SQA組、SEPG組）v 質(zhì)量計劃制定的步驟（6步）v 軟件評審的方法（5種）、技術(shù)（檢查表技術(shù)、場景分析技術(shù)）、過程v 缺陷趨勢分析、缺陷分布分析、魚骨圖v 質(zhì)量度量 代碼質(zhì)量 產(chǎn)品質(zhì)量 測試有效性v 過程質(zhì)量度量 過程缺陷密度 整體缺陷清除率 階段性缺陷清除率 缺陷到達模式792021-9-4思考題和課后作業(yè)思考題和課后作業(yè)v簡要說明評審的流程v談?wù)勅毕葳厔莘治龊头植挤治鲇惺裁床煌?，他們對質(zhì)量管理工作有什么幫助v用來測試軟件過程質(zhì)量的指標有哪些？v實驗題：針對選定系統(tǒng)，完成項目的質(zhì)量計劃802021-9-4Q & A溫馨提示：本PPT課件下載后，即可編輯修改，也可直接使用。（希望本課件對您有所幫助）