第6章項(xiàng)目質(zhì)量管理

軟件項(xiàng)目管理第6章項(xiàng)目質(zhì)量管理Brucencepuwork@如何看待的項(xiàng)目的質(zhì)量？2023/2/32實(shí)例曾經(jīng)對一個國際性的軟件公司作了一個調(diào)查，選擇了由質(zhì)量問題引起的10項(xiàng)額外工作開發(fā)人員修正缺陷測試人員驗(yàn)證缺陷返工設(shè)計或代碼完成后的需求變化不清楚或無效的缺陷報告代碼完成后補(bǔ)充的測試用例由于缺陷修復(fù)后所做的回歸測試測試環(huán)境設(shè)置錯誤產(chǎn)品發(fā)布后遺漏的缺陷驗(yàn)證為產(chǎn)品發(fā)布后遺漏的缺陷出補(bǔ)丁包2023/2/33實(shí)例（續(xù)）統(tǒng)計結(jié)果表明，由于質(zhì)量問題造成的成本（劣質(zhì)成本）竟高達(dá)45.86%，差不多占開發(fā)總成本的一半。所以，軟件項(xiàng)目質(zhì)量管理，不僅有助于提高軟件產(chǎn)品質(zhì)量，而且有助于縮短開發(fā)周期，降低成本2023/2/34冰山一角2023/2/35真理產(chǎn)品質(zhì)量是生產(chǎn)出來的，不是檢驗(yàn)出來的?！ご髅鳜F(xiàn)實(shí)：很多軟件公司投入大量時間和精力來發(fā)現(xiàn)和修正錯誤（需求、設(shè)計、實(shí)現(xiàn)），導(dǎo)致進(jìn)度延期。少了些質(zhì)量管理《理解專業(yè)程序員》中，扔進(jìn)垃圾代碼，因?yàn)殄e誤無法交工而不斷修改，最終開發(fā)出較好代碼的故事2023/2/36軟件的質(zhì)量管理貫穿了整個軟件開發(fā)周期。質(zhì)量管理不僅確保項(xiàng)目最終交付的產(chǎn)品滿足質(zhì)量要求，而且要保證項(xiàng)目實(shí)施過程中階段性成果的質(zhì)量。也就是保證軟件需求分析、設(shè)計和代碼的質(zhì)量，包括各種文檔的質(zhì)量正如ISO8402所規(guī)定和倡導(dǎo)的：“質(zhì)量管理是指確定質(zhì)量方針、目標(biāo)和職責(zé)，并通過質(zhì)量體系中的質(zhì)量策劃、質(zhì)量控制、質(zhì)量保證和質(zhì)量改進(jìn)來使其實(shí)現(xiàn)的所有管理職能的全部活動?！辟|(zhì)量管理2023/2/37項(xiàng)目質(zhì)量管理項(xiàng)目質(zhì)量管理質(zhì)量規(guī)劃（始）

.1輸入.1事業(yè)環(huán)境因素.2組織過程資產(chǎn)

.3項(xiàng)目范圍說明書

.4項(xiàng)目管理計劃.2工具和技術(shù)

.1成本效益分析

.2基準(zhǔn)對照.3

實(shí)驗(yàn)設(shè)計

.4質(zhì)量成本.5其他質(zhì)量計劃工具.3輸出

.1質(zhì)量管理計劃

.2質(zhì)量衡量指標(biāo)

.3質(zhì)量檢查表

.4過程改進(jìn)計劃

.5質(zhì)量基準(zhǔn)

.6項(xiàng)目管理計劃(更新)

執(zhí)行質(zhì)量保證（中）

.1輸入.1質(zhì)量管理計劃

.2質(zhì)量測量指標(biāo)

.3過程改進(jìn)計劃

.4工作績效信息.5批準(zhǔn)的變更請求.6質(zhì)量控制度量.7實(shí)現(xiàn)的變更請求.8實(shí)現(xiàn)的糾正措施.9實(shí)現(xiàn)的缺陷修復(fù).10實(shí)現(xiàn)的預(yù)防措施.2工具和技術(shù).1質(zhì)量計劃工具和技術(shù).2質(zhì)量審計

.3過程分析.4質(zhì)量控制工具和技術(shù).3輸出.1請求的變更.2推薦的糾正措施.3組織過程資產(chǎn)(更新).4項(xiàng)目管理計劃(更新)執(zhí)行質(zhì)量控制（尾）

.1輸入.1質(zhì)量管理計劃

.2質(zhì)量測量指標(biāo).3質(zhì)量檢查表

.4組織過程資產(chǎn)

.5工作績效信息.6批準(zhǔn)的變更請求.7可交付成果.2工具和技術(shù)

.1因果圖

.2控制圖.3流程圖.4直方圖

.5帕雷托圖.6趨勢圖.7散點(diǎn)圖.8統(tǒng)計抽樣.9檢查

.10缺陷修復(fù)審查.3輸出.1質(zhì)量控制度量.2確認(rèn)的缺陷修復(fù).3質(zhì)量基準(zhǔn)(更新).4推薦的糾正措施.5推薦的預(yù)防措施.6請求的變更.7推薦的缺陷修復(fù).8組織過程資產(chǎn)(更新).9確認(rèn)的可交付成果.10項(xiàng)目管理計劃(更新)2023/2/38第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/39質(zhì)量管理概論不同的質(zhì)量管理方式：病入膏肓及早治療提前預(yù)防2023/2/3106.1質(zhì)量管理概述軟件質(zhì)量控制

(SQC，SoftwareQualityControl)是科學(xué)地測量過程狀態(tài)的基本的方法。就象汽車表盤上的儀器，可以了解行駛中的轉(zhuǎn)速、速度、油量等。軟件質(zhì)量保證

(SQA，SoftwareQualityAssurance)則是過程和程序的參考與指南的集合。就像汽車中的用戶手冊。軟件質(zhì)量管理

(SQM，SoftwareQualityManagement)才是操作的誓學(xué)，教你如何駕車，建立質(zhì)量文化和管理思想。

2023/2/311四種不同的質(zhì)量管理水平檢查，通過檢驗(yàn)保證產(chǎn)品的質(zhì)量，符合規(guī)格的軟件產(chǎn)品為合格品，不符合規(guī)格的產(chǎn)品為次品。只能判斷產(chǎn)品質(zhì)量，不檢驗(yàn)工藝流程、設(shè)計、服務(wù)等，不能提高軟件質(zhì)量。相當(dāng)于“軟件測試/質(zhì)量控制”;保證，質(zhì)量目標(biāo)通過軟件開發(fā)部門來實(shí)現(xiàn)，制定質(zhì)量目標(biāo)和質(zhì)量計劃，保證軟件開發(fā)流程合理性、流暢性和穩(wěn)定性。相當(dāng)于初期的“質(zhì)量保證”;預(yù)防，軟件質(zhì)量以預(yù)防為主，以過程管理為重，把質(zhì)量的保證工作重點(diǎn)放在過程管理上。從需求、設(shè)計開始就引入預(yù)防思想，相當(dāng)于成熟的“質(zhì)量保證”;完美，以客戶為中心，貫穿于軟件開發(fā)生存期過程，全員參與，追求卓越，相當(dāng)于“全面軟件質(zhì)量管理”。2023/2/312質(zhì)量管理的支持質(zhì)量管理技術(shù)（開發(fā)技術(shù)成熟度、開發(fā)工具、自動化測試水平）方法（開發(fā)模型、開發(fā)流程）基礎(chǔ)設(shè)施（質(zhì)量文化、開發(fā)環(huán)境、標(biāo)準(zhǔn)體系2023/2/313技術(shù)層次的質(zhì)量管理支持制定編程規(guī)范，有利于整體風(fēng)格的統(tǒng)一、提高代碼可讀性、可維護(hù)性、可擴(kuò)展性組織應(yīng)通過制定統(tǒng)一的模板來規(guī)范文檔，統(tǒng)一文檔內(nèi)容和風(fēng)格實(shí)施覆蓋生命周期的軟件測試，包括單元、集成、系統(tǒng)測試，不僅要動態(tài)測試，也要靜態(tài)測試（需求分析、系統(tǒng)設(shè)計需要評審和驗(yàn)證）采用統(tǒng)計方法（一般是量化的數(shù)理統(tǒng)計分析）揭示產(chǎn)品特征和軟件開發(fā)過程特征，發(fā)現(xiàn)各種不一致性問題2023/2/314基礎(chǔ)設(shè)施2023/2/315第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/316組織保證管理層測試組SQA組SEPG組項(xiàng)目組2023/2/317組織保證（續(xù)）管理組：很強(qiáng)的“質(zhì)量第一”的意識，能制定有利于保證和提高質(zhì)量的正確策略和方針，在整個組織中營造良好的質(zhì)量文化。SQA組（監(jiān)督）：從流程上對軟件質(zhì)量進(jìn)行跟蹤、控制和改進(jìn)。即監(jiān)督項(xiàng)目按已經(jīng)定義的流程進(jìn)行，并符合已定義的相關(guān)標(biāo)準(zhǔn)。如要求建立相關(guān)文檔、需求變更控制測試組（執(zhí)行）：負(fù)責(zé)對軟件產(chǎn)品進(jìn)行全面的測試，包括需求評審、設(shè)計評審、功能和性能測試等，從中找出所存在的缺陷。測試組面向產(chǎn)品，進(jìn)行事后檢查。SEPG組（立法）：軟件工程過程組，通常有軟件專家組成，領(lǐng)導(dǎo)和協(xié)調(diào)過程改進(jìn)的小組。其主要任務(wù)是推動企業(yè)所應(yīng)用的過程的定義、維護(hù)和改進(jìn)。類似于一個“立法”機(jī)構(gòu)2023/2/318第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/319質(zhì)量計劃概述質(zhì)量計劃：進(jìn)行項(xiàng)目質(zhì)量管理，實(shí)施項(xiàng)目質(zhì)量方針和目標(biāo)的具體規(guī)劃。質(zhì)量計劃通常在組織的質(zhì)量方針指導(dǎo)下定義項(xiàng)目的質(zhì)量目標(biāo)，描述項(xiàng)目質(zhì)量管理中所需的資源、職責(zé)分配，說明如何采用正確的流程和操作程序、質(zhì)量控制方法和評審技術(shù)來保證質(zhì)量。軟件質(zhì)量計劃需要覆蓋軟件開發(fā)和維護(hù)的整個生命周期，即需要對需求分析、設(shè)計、編碼、測試、部署提出質(zhì)量目標(biāo)和要求，并就質(zhì)量控制內(nèi)容、方法和手段給出建議和指導(dǎo)。2023/2/3206.3質(zhì)量計劃6.3.1質(zhì)量計劃的內(nèi)容6.3.2質(zhì)量計劃制定的步驟6.3.3如何制定有效的質(zhì)量計劃6.3.4質(zhì)量計劃的實(shí)施和控制2023/2/3216.3.1質(zhì)量計劃的內(nèi)容目的和范圍參考的文件列表質(zhì)量目標(biāo)，總體目標(biāo)，分階段目標(biāo)，分項(xiàng)目標(biāo)質(zhì)量的任務(wù)，包括組織流程說明會，關(guān)鍵成果評審參與質(zhì)量管理的相關(guān)人員及其責(zé)任對一些關(guān)鍵文檔提出要求。如測試計劃，配置管理計劃重申適合項(xiàng)目的相關(guān)標(biāo)準(zhǔn)。如文檔模板標(biāo)準(zhǔn)，代碼編寫標(biāo)準(zhǔn)評審的流程和標(biāo)準(zhǔn)。如明確區(qū)分代碼評審和技術(shù)評審的不同點(diǎn)配置管理要求，如代碼版本控制、需求變更控制問題報告和處理系統(tǒng)采用的質(zhì)量控制工具、技術(shù)和方法等2023/2/322質(zhì)量計劃模板參照

項(xiàng)目概述實(shí)施策略項(xiàng)目組織質(zhì)量保證對象分析及選擇質(zhì)量保證任務(wù)劃分實(shí)施計劃資源計劃記錄的收集、維護(hù)與保存樣例詳見P1412023/2/323質(zhì)量評審的內(nèi)容和手段內(nèi)容需求說明評審設(shè)計文檔評審測試計劃評審功能性審核（內(nèi)審）物理性審核（內(nèi)審）管理評審手段內(nèi)審：部門內(nèi)部審查自己的工作，或者由一個獨(dú)立部門審查其他各部門的工作，以檢查組織內(nèi)部是否遵守已有的模板、規(guī)則和流程等復(fù)審：在軟件開發(fā)生命周期每個階段結(jié)束之前，都正式用結(jié)束標(biāo)準(zhǔn)對該階段的階段性成果進(jìn)行嚴(yán)格的技術(shù)審查。2023/2/324質(zhì)量計劃制定的步驟（1）了解項(xiàng)目的基本概況，收集項(xiàng)目有關(guān)資料重點(diǎn)了解項(xiàng)目的目標(biāo)、用戶需求和項(xiàng)目的實(shí)施范圍確定項(xiàng)目的質(zhì)量目標(biāo)

先根據(jù)項(xiàng)目總體目標(biāo)和用戶需求確定項(xiàng)目的質(zhì)量總目標(biāo)再根據(jù)項(xiàng)目組成和劃分來分解項(xiàng)目質(zhì)量目標(biāo)然后建立各個具體的質(zhì)量目標(biāo)

確定圍繞質(zhì)量目標(biāo)的工作任務(wù)

評審、跟蹤、統(tǒng)計分析等明確項(xiàng)目質(zhì)量管理組織機(jī)構(gòu)

配備各級質(zhì)量管理人員、設(shè)備資源確定質(zhì)量管理人員的角色和責(zé)任，建立質(zhì)量管理機(jī)構(gòu)2023/2/325質(zhì)量計劃制定的步驟（2）-項(xiàng)目質(zhì)量責(zé)任表角色質(zhì)量責(zé)任項(xiàng)目經(jīng)理協(xié)助質(zhì)量保證人員、測試組長的工作。進(jìn)行全程的質(zhì)量跟蹤，報告質(zhì)量問題，負(fù)責(zé)質(zhì)量改進(jìn)措施的實(shí)施質(zhì)量保證人員對開發(fā)和測試過程進(jìn)行質(zhì)量控制，制定質(zhì)量計劃并負(fù)責(zé)實(shí)施、監(jiān)控，組織所要求的各類評審會議等系統(tǒng)分析員負(fù)責(zé)需求評審的組織和實(shí)施，保證需求定義符合相關(guān)的規(guī)范架構(gòu)師開發(fā)組負(fù)責(zé)人，負(fù)責(zé)設(shè)計的評審編程人員負(fù)責(zé)詳細(xì)設(shè)計、編程、單元測試測試組組長參與需求、設(shè)計評審等會議。制定測試計劃和測試用例的評審，執(zhí)行測試的質(zhì)量跟蹤測試人員編寫測試用例，并參與評審文檔編寫人員審查相關(guān)文檔是否采用了最新的模板，是否符合文檔規(guī)范的要求2023/2/326質(zhì)量計劃制定的步驟（3）制定項(xiàng)目質(zhì)量控制程序

項(xiàng)目質(zhì)量控制工作程序初始的檢查試驗(yàn)和標(biāo)識程序項(xiàng)目實(shí)施過程中的質(zhì)量檢查程序不合格項(xiàng)目產(chǎn)品的控制程序各類項(xiàng)目實(shí)施質(zhì)量記錄的控制程序和交驗(yàn)程序項(xiàng)目質(zhì)量計劃的評審

如果項(xiàng)目規(guī)模較大，可以按照子項(xiàng)目，或根據(jù)項(xiàng)目進(jìn)度分階段編制和評審項(xiàng)目計劃2023/2/3276.3.3如何制定有效的質(zhì)量計劃質(zhì)量計劃有效性體現(xiàn)在：項(xiàng)目質(zhì)量計劃要保證項(xiàng)目按計劃期限完成要處理好項(xiàng)目質(zhì)量計劃與其他計劃之間的關(guān)系保證項(xiàng)目質(zhì)量計劃有效性的幾種方法：利益/成本分析。效益與成本之比盡可能的大。利益：減少重復(fù)性工作（避免返工），增加投資者的滿意度成本：項(xiàng)目質(zhì)量管理活動的付出基準(zhǔn)：以其他同類歷史項(xiàng)目的質(zhì)量計劃進(jìn)行比較，為改進(jìn)項(xiàng)目實(shí)施過程提供思路和可參考的標(biāo)準(zhǔn)。流程圖：因果圖：主要用來尋找引起質(zhì)量問題的根本原因系統(tǒng)流程圖或處理流程圖：可以幫助找出解決所遇質(zhì)量問題的相關(guān)方法試驗(yàn)設(shè)計。嘗試找出最影響質(zhì)量的因素、驗(yàn)證質(zhì)量管理的合理性2023/2/3286.3.4質(zhì)量計劃的實(shí)施和控制質(zhì)量計劃主要是獲得產(chǎn)生質(zhì)量缺陷的原因，從而減少軟件缺陷或避免將來犯類似錯誤通過設(shè)置檢查點(diǎn)、驗(yàn)證點(diǎn)，對階段性成果進(jìn)行評審或完成質(zhì)量評估，以確定項(xiàng)目階段性成果是否達(dá)到所設(shè)定的質(zhì)量標(biāo)準(zhǔn)。項(xiàng)目收尾階段的質(zhì)量控制是一個非常重要而又容易忽視的內(nèi)容。它需要檢查項(xiàng)目文件資料的完備性，包括評審會議記錄、測試報告等。同時進(jìn)行項(xiàng)目總結(jié)2023/2/3296.3.4質(zhì)量計劃的實(shí)施和控制（續(xù)）加強(qiáng)對質(zhì)量計劃執(zhí)行情況的檢查，及時發(fā)現(xiàn)問題在項(xiàng)目總體目標(biāo)不變的前提下，應(yīng)根據(jù)原質(zhì)量計劃和實(shí)際情況進(jìn)行比較分析，找出問題產(chǎn)生的根本原因針對原因，制定出相應(yīng)的技術(shù)保證措施，對原計劃做出適當(dāng)?shù)恼{(diào)整，以確保項(xiàng)目質(zhì)量總目標(biāo)的圓滿實(shí)現(xiàn)。2023/2/330第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/3316.4軟件評審方法和過程6.4.1軟件評審的方法和技術(shù)6.4.2角色和責(zé)任6.4.3軟件評審過程6.4.4如何有效地組織評審2023/2/332軟件評審不管你有沒有發(fā)現(xiàn)他們，缺陷總是存在，問題只是你最終發(fā)現(xiàn)它們時，需要多少糾正成本。評審的投入把質(zhì)量成本從昂貴的、后期返工轉(zhuǎn)變?yōu)樵缙诘娜毕莅l(fā)現(xiàn)?！枴ね?/p>

2023/2/333軟件評審的方法臨時評審（Adhocreview）：自發(fā)使用輪查（Passroud）：郵件分發(fā)審查，異步進(jìn)行互為復(fù)審：兩個人工作內(nèi)容和技術(shù)比較接近，涉及人員很少，復(fù)審效率較高，如極限編程走查（Walkthrough）：對評審對象要從頭到尾檢查一遍審查（Inspection）：系統(tǒng)化、嚴(yán)密的集體評審方法最不正式最正式臨時評審輪查互為復(fù)審走查會議審查2023/2/334軟件評審方法（續(xù)）在軟件開發(fā)過程中，各種評審技術(shù)交替使用，其原則：在不同的開發(fā)階段和不同的場合選擇適合的評審方法需求和設(shè)計評審初稿：輪查需求和設(shè)計最終定稿之前：評審會議代碼評審：互為評審、自發(fā)采用“臨時評審”對最可能產(chǎn)生較大風(fēng)險的工作成果，要采用最正式的評審方法需求分析報告：走查或者會議評審核心代碼：走查或者會議評審2023/2/335軟件評審技術(shù)檢查表技術(shù)：簡單、提高評審效率、改進(jìn)評審質(zhì)量。例如缺陷檢查表列出容易出現(xiàn)的典型錯誤，幫助找出缺陷，排除隱患場景分析技術(shù)：更能發(fā)現(xiàn)錯誤和問題，耗時多。多用于需求文檔評審，發(fā)現(xiàn)遺漏和多余的需求工具：提高效率，如IBM的RRP、NASA的ARM，對導(dǎo)入的文檔統(tǒng)計分析，找出各種詞語的出現(xiàn)概率，對完整性和二義性進(jìn)行分析2023/2/3366.4.2評審過程中的角色和責(zé)任小組組長作者讀者記錄者評審員審核者協(xié)調(diào)者2023/2/3376.4.3軟件評審過程（1）2023/2/338軟件評審過程（2）計劃確定被評審對象確定期望達(dá)到的評審目標(biāo)計劃選用的評審方法會議準(zhǔn)備確定評審組長：經(jīng)驗(yàn)豐富、技術(shù)能力強(qiáng)、工作認(rèn)真負(fù)責(zé)、不能和作者有密切關(guān)系（保持評審客觀性）選定評審材料，找出哪些是必須評審的分發(fā)評審材料制定相應(yīng)的活動進(jìn)度表，提前2-3天通知小組成員2023/2/339軟件評審過程（3）召開會議：簡要說明待審查內(nèi)容、重申會議目標(biāo)詳細(xì)說明評審材料，了解各評審員對材料的了解是否一致如理解不一致，容易發(fā)現(xiàn)問題（二義性、遺漏、錯誤假設(shè)），從而找出缺陷記錄問題和缺陷記錄員向小組重述記錄的缺陷評審決議座次圖主持人作者記錄員列席人員內(nèi)審員技術(shù)專業(yè)人員2023/2/340軟件評審過程（4）評審決議的幾種情況接受有條件接受：修訂其中的一些小缺陷后通過不能接受評審未完成問題跟蹤（返工）驗(yàn)證作者是否恰當(dāng)?shù)亟鉀Q了評審會上所列出的問題考慮是否需要再次召開評審會議2023/2/341評審注意事項(xiàng)明確自己的角色和責(zé)任；熟悉評審內(nèi)容，為評審做好準(zhǔn)備，做細(xì)做到位；關(guān)注問題，針對問題闡述觀點(diǎn)，而不是對人；可以分別討論主要的問題和次要的問題；在會議前或者會議后可以就存在的問題提出自己的建設(shè)性的意見；提高溝通能力，采取適當(dāng)?shù)?、靈活的表述方式；對發(fā)現(xiàn)的問題，要跟蹤到底。2023/2/3426.4.4如何有效地組織評審什么叫有效評審：盡可能、盡早地發(fā)現(xiàn)問題和缺陷高效、省時、省力實(shí)施要點(diǎn)：把握好流程和評審目標(biāo)認(rèn)真、仔細(xì)地閱讀評審材料，不斷思考善于提問充分溝通一切圍繞用戶需求進(jìn)行。用戶？用戶的操作習(xí)慣？用戶的業(yè)務(wù)流程？應(yīng)用場景和操作模式2023/2/343評審組織方法分層評審方法（高層次、低層次）先總體后細(xì)節(jié)，避免過早陷入細(xì)節(jié)，只見樹木，不見森林高層次評審：主要評審產(chǎn)品是否滿足客戶的需求和期望，是否具有合理的功能層次性和完備性，能否滿足客戶各個方面的需求低層次評審：逐字逐行地評審文檔的各項(xiàng)描述，包括文字、圖表，要求準(zhǔn)確、完整、清晰。比如，需要較高的性能、多數(shù)情況下支持…..Web頁的刷新響應(yīng)時間不超過3秒（不專業(yè)、不明確）每一個頁面訪問的響應(yīng)時間不超過3秒2023/2/344評審組織方法（續(xù)）分類評審方法（分業(yè)務(wù)需求、功能需求、非功能需求、用戶操作性需求等）業(yè)務(wù)需求：最基本的需求、核心需求。用戶的高層代表關(guān)注。資深人員（測試經(jīng)理）參加評審。功能性需求：用戶的中層人員關(guān)注。用戶的中層人員和各個功能模塊負(fù)責(zé)人參加評審。操作性需求：用戶的操作人員關(guān)注。具體操作人員和測試工程師參加評審分階段評審方法，比如：目標(biāo)性需求形成時，系統(tǒng)功能框架形成時，當(dāng)功能細(xì)化成幾個部分后，對每個部分分別進(jìn)行，對關(guān)鍵的非功能性進(jìn)行單獨(dú)評審對整體的需求進(jìn)行全面評審2023/2/345第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/3466.5缺陷預(yù)防和跟蹤分析6.5.1缺陷預(yù)防6.5.2缺陷分析6.5.3魚骨圖

軟件缺陷不僅僅局限于程序功能的問題，任何與用戶需求不符合的地方都是缺陷。需求說明、設(shè)計文檔、測試用例等文檔中也同樣存在缺陷2023/2/3476.5.1缺陷預(yù)防-why質(zhì)量大師克勞士比提倡“零缺陷管理”，在傳統(tǒng)工業(yè)工程中深受歡迎。零缺陷管理的中心思想：第一次就把事情做正確，從而消除劣質(zhì)成本。項(xiàng)目管理既要保證質(zhì)量又要降低成本，最佳結(jié)合點(diǎn)就是要求每一個人“第一次把事情做好”軟件產(chǎn)品的質(zhì)量是做出來的，不是測試出來的。上千人的印度軟件公司，只有5-6個SQA，無測試團(tuán)隊(duì)，軟件質(zhì)量依舊很好。2023/2/3486.5.1缺陷預(yù)防-how從流程上加強(qiáng)控制建立和規(guī)范工作流程，加強(qiáng)評審過程改進(jìn)采用有效的工作方法代碼評審單元測試提高個人的技術(shù)水平自我學(xué)習(xí)和提高延伸：測試驅(qū)動開發(fā)TDD2023/2/3496.5.2缺陷分析（1）缺陷分析：將軟件開發(fā)、運(yùn)行過程中產(chǎn)生的缺陷進(jìn)行必要的收集，對缺陷的信息進(jìn)行分類和匯總統(tǒng)計作用：通過缺陷分析，可以發(fā)現(xiàn)各種類型缺陷發(fā)生的概率，掌握缺陷集中的區(qū)域，明確缺陷的發(fā)展趨勢，了解缺陷產(chǎn)生的主要原因。以便有針對性地提出遏制缺陷發(fā)生的措施，降低缺陷數(shù)量。缺陷收集工具：IBM的RTC、MantisBT、Bugfree、Bugzilla2023/2/3506.5.2缺陷分析（2）缺陷趨勢分析（實(shí)時、累積）缺陷分布分析

（如缺陷產(chǎn)生的原因、階段、來源）2023/2/351趨勢趨勢分析缺陷趨勢分析（實(shí)時、累積）：針對缺陷數(shù)目隨時間而不斷變化的趨勢進(jìn)行分析，了解缺陷的發(fā)現(xiàn)或修正過程是否符合期望的規(guī)律性，是否出現(xiàn)異?，F(xiàn)象。需要統(tǒng)計每天的缺陷發(fā)現(xiàn)和修訂情況。2023/2/352缺陷發(fā)展趨勢分析示例2023/2/353缺陷分布分析及示例不同模塊的缺陷分布圖不同階段的缺陷分布圖缺陷分布分析：一種橫向分析，即分析缺陷在功能模塊、缺陷類型、缺陷產(chǎn)生原因等不同方面的分布情況。2023/2/354分布分析示例2不同級別的缺陷分布圖2023/2/3556.5.3魚骨圖可以更全面地探討各種類別的原因鼓勵通過自由討論發(fā)揮大家的創(chuàng)造性提供問題與各類原因之間關(guān)系的直觀表示

魚骨圖，也叫因果分析圖，它是分析影響事物質(zhì)量形成的諸要素間因果關(guān)系的一種分析圖。因?yàn)槠湫螤钕耵~骨，俗稱魚骨圖。2023/2/356魚骨圖的應(yīng)用過程魚骨圖分析法要完成從主刺到小刺的思維和分析過程，一般分三步：確定問題：或?qū)嶋H問題，或潛在問題找出問題的主要原因：可以采用5M方法Manpower（人力）：造成問題產(chǎn)生的人為因素是什么Machinery（機(jī)械）：軟硬件條件對事件的影響Materials（物料）：基礎(chǔ)的準(zhǔn)備以及原材料Methods（方法）：與事件相關(guān)的方式與方法是否正確有效Mother-nature（環(huán)境）：內(nèi)、外部環(huán)境因素的影響根據(jù)問題類別，確定細(xì)節(jié)原因2023/2/357示例2023/2/358工具——XMind2008Pro2023/2/359第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/3606.6質(zhì)量度量6.6.1度量要素6.6.2基于缺陷的質(zhì)量度量2023/2/361質(zhì)量度量的作用有效的溝通改進(jìn)可見性。盡早的發(fā)現(xiàn)和更正問題。作出關(guān)鍵的權(quán)衡。跟蹤特定的項(xiàng)目目標(biāo)。按時？質(zhì)量改進(jìn)？管理風(fēng)險。風(fēng)險降低了嗎？有助于決策。計劃未來的項(xiàng)目。做為歷史數(shù)據(jù)！2023/2/3626.6.1度量要素項(xiàng)目度量：項(xiàng)目的規(guī)模、成本、工作量、進(jìn)度、生產(chǎn)力、風(fēng)險、顧客滿意度產(chǎn)品度量：以質(zhì)量度量為中心，包括功能性、可靠性、易用性、可維護(hù)性、可移植性過程度量：成熟度、管理、生命周期、生產(chǎn)率等

2023/2/363度量的表示方法數(shù)據(jù)圖表模型：為了某種特定目的而對研究對象所做的一種簡化的描述或者模擬。可以幫助澄清元素間的相互關(guān)系，識別關(guān)鍵元素，使得復(fù)雜信息簡單易懂。2023/2/3646.6.2基于缺陷的質(zhì)量度量--代碼質(zhì)量

代碼質(zhì)量BTPi

:測試過程中發(fā)現(xiàn)的各種級別缺陷的數(shù)目。

BFi

:產(chǎn)品發(fā)布之后發(fā)現(xiàn)的各種級別缺陷的數(shù)目。Wli

:各個缺陷的權(quán)重系數(shù)，詳見P159頁的表6-6WTP：測試過程中發(fā)現(xiàn)的缺陷的權(quán)重（測試小組內(nèi)、外發(fā)現(xiàn)的缺陷）WF產(chǎn)品發(fā)布之后的缺陷的權(quán)重KCSI：新增加的和修改的千行代碼數(shù)代碼質(zhì)量指標(biāo)：這個值越低，說明發(fā)現(xiàn)的缺陷越少或者嚴(yán)重性越低，同時說明代碼質(zhì)量越高代碼質(zhì)量=2023/2/3656.6.2基于缺陷的質(zhì)量度量—產(chǎn)品質(zhì)量

產(chǎn)品質(zhì)量WF產(chǎn)品發(fā)布之后的缺陷的權(quán)重KCSI：新增加的和修改的千行代碼數(shù)指標(biāo)含義：這個指標(biāo)值越低，說明遺留給客戶的缺陷越少或者嚴(yán)重性越低，同時說明產(chǎn)品發(fā)布的質(zhì)量越高。產(chǎn)品質(zhì)量=2023/2/3666.6.2基于缺陷的質(zhì)量度量—測試有效性

測試有效性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)重指標(biāo)含義：這個指標(biāo)值越高，約接近100%，說明測試小組的有效性（效率）越高。做為高水平的測試團(tuán)隊(duì)，可以達(dá)到90-95%測試有效性=2023/2/367第6章項(xiàng)目質(zhì)量管理6.1質(zhì)量管理概述6.2項(xiàng)目質(zhì)量的組織保證6.3質(zhì)量計劃6.4軟件評審方法和過程6.5缺陷預(yù)防和跟蹤分析6.6質(zhì)量度量6.7過程質(zhì)量管理2023/2/3686.7過程質(zhì)量管理6.7.1過程質(zhì)量度量6.7.2缺陷移除和預(yù)防2023/2/3696.7.1過程質(zhì)量度量產(chǎn)品的質(zhì)量在一定程度上依賴于過程的質(zhì)量。軟件過程質(zhì)量的度量：對軟件開發(fā)過程中各個方面質(zhì)量指標(biāo)進(jìn)行度量，目的在于預(yù)測過程的未來性能，減少過程結(jié)果的偏差，對軟件過程的行為進(jìn)行目標(biāo)管理，為過程控制、過程評價、持續(xù)改善建立量化管理奠定基礎(chǔ)過程質(zhì)量度量的指標(biāo)有：過程缺陷密度整體缺陷清除率階段性缺陷清除率缺陷到達(dá)模式2023/2/370過程質(zhì)量度量—過程缺陷密度過程缺陷密度（DensityInProcessFaults，DIPF）：用來判定過程產(chǎn)品的質(zhì)量，以及檢驗(yàn)過程的執(zhí)行程度。Dn：某階段或整個項(xiàng)目被發(fā)現(xiàn)的缺陷數(shù)Sp：被測試的軟件產(chǎn)品規(guī)模數(shù)（如代碼行數(shù)、功能點(diǎn)數(shù)、對象數(shù)等）當(dāng)DIPF過低時，應(yīng)考慮兩種情況：軟件產(chǎn)品質(zhì)量很好，缺陷很少方法或者能力不到位，不能發(fā)現(xiàn)產(chǎn)品中的某部分缺陷DIPF=Dn/Sp

2023/2/371過程質(zhì)量度量—整體缺陷清除率缺陷被清除的程度能反映出項(xiàng)目組在質(zhì)量上的工作表現(xiàn)，也能反映待發(fā)布的產(chǎn)品質(zhì)量。如果開發(fā)中大量的嚴(yán)重缺陷未被清除，可能阻止測試進(jìn)行，也必然影響軟件過程的質(zhì)量和性能缺陷清除率（DefectRemovalEfficiency，DRE）度量缺陷清除的程度。2023/2/372過程質(zhì)量度量—整體缺陷清除率（續(xù)）假定F：軟件規(guī)模的功能點(diǎn)數(shù)D1：軟件開發(fā)過程中發(fā)現(xiàn)的所有缺陷數(shù)D2：軟件發(fā)布后發(fā)現(xiàn)的缺陷數(shù)D：發(fā)現(xiàn)的總?cè)毕輸?shù)。D=D1+D2。則質(zhì)