第四章 軟件項目質(zhì)量管理.ppt_第1頁
第四章 軟件項目質(zhì)量管理.ppt_第2頁
第四章 軟件項目質(zhì)量管理.ppt_第3頁
第四章 軟件項目質(zhì)量管理.ppt_第4頁
第四章 軟件項目質(zhì)量管理.ppt_第5頁
已閱讀5頁,還剩39頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、第四章 軟件項目質(zhì)量管理,軟件項目管理,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第一節(jié) 軟件質(zhì)量管理的基本概念,軟件質(zhì)量是指軟件滿足明確說明或者隱含的需求的程度。 用戶需求是衡量軟件質(zhì)量的基礎(chǔ)。 除滿足明確定義的需求外,還要滿足隱含的需求。,軟件質(zhì)量的重要性,軟件項目的三大目標:,質(zhì)量,進度,費用,軟件質(zhì)量問題可能導致經(jīng)濟損失甚至災(zāi)難性的后果。 質(zhì)量是軟件產(chǎn)品和軟件組織的生命線。 質(zhì)量問題會增加開發(fā)和維護軟件產(chǎn)品的成本。,軟件質(zhì)量的重要性,軟件質(zhì)量屬性,軟件質(zhì)量屬性,可靠性,可用性,安全性,可維護性,保密性,軟件質(zhì)量,功

2、能,性能,易用性,可信性,軟件質(zhì)量的形成,軟件的質(zhì)量形成于產(chǎn)品或者服務(wù)的開發(fā)過程中,而不是事后的檢查(如測試)。 20世紀80年代起,質(zhì)量管理逐步從單一的關(guān)注產(chǎn)品,轉(zhuǎn)移到關(guān)注生產(chǎn)好產(chǎn)品的過程上,并且將過程的作用擴大到了組織運行的所有領(lǐng)域。,質(zhì)量產(chǎn)生于過程,當過程不斷被重復(fù),其性能會趨于穩(wěn)定 結(jié)果可預(yù)測 對現(xiàn)行執(zhí)行可監(jiān)測,質(zhì)量得到保證,實施的過程性能,穩(wěn)定過程的上下控制界,特殊原因造成過程性能不穩(wěn)定。 根除特殊原因,使過程性能穩(wěn)定,防止質(zhì)量問題的出現(xiàn)。,質(zhì)量產(chǎn)生于過程,造成不穩(wěn)定的特殊原因,質(zhì)量成本(CoQ),質(zhì)量成本是為了達到產(chǎn)品或服務(wù)的質(zhì)量而付出的所有努力的總成本,包括三部分: 預(yù)防成本:為

3、防止將缺陷引入軟件而進行的預(yù)防工作所消耗的費用。 評價成本:檢查軟件是否包含缺陷的工作所消耗的費用。 失效成本:修復(fù)缺陷工作所消耗的成本。 PAF(Prevention / Appraisal / Failure)成本模型,質(zhì)量成本(CoQ),質(zhì)量成本(CoQ),在項目早期預(yù)防和檢測缺陷比在項目晚期檢測和排除缺陷更有效、更節(jié)省成本。,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第二節(jié) 軟件質(zhì)量控制,質(zhì)量控制(Quality Control, QC)是確定項目結(jié)果與質(zhì)量標準是否相符,并及時糾正產(chǎn)品缺陷的過程。 質(zhì)量控制的主要手

4、段是驗證與確認( V&V ) 驗證(Verification):是否正確地構(gòu)造了產(chǎn)品?以開發(fā)者的視角進行。 確認(Validation):是否構(gòu)造了正確的產(chǎn)品?以用戶的視角進行。,軟件項目中的QC活動,需求分析,需求評審,設(shè)計,設(shè)計評審,編碼,代碼審查,系統(tǒng)測試,界面原型,需求確認,需求確認,確認測試,測試開發(fā),質(zhì)量控制方法,質(zhì)量控制方法,靜態(tài)方法:評審,技術(shù)評審,代碼評審,動態(tài)方法:測試,單元測試,集成測試,確認測試,技術(shù)評審(Technical Review),技術(shù)評審是指在完成一項工作后,把工作產(chǎn)品分發(fā)給合作者,讓合作者檢查其中的缺陷。然后開會討論工作產(chǎn)品并產(chǎn)生需要返工的缺陷列表。 技術(shù)

5、評審的主要對象:需求和設(shè)計規(guī)格說明、測試計劃、用戶手冊等。,技術(shù)評審流程,組織召開評審會議:一般應(yīng)有35個相關(guān)人員參加,會前每個參加者做好準備,評審會議一般不超過兩個小時。 在評審會議上,由開發(fā)小組對提交的評審對象進行講解。 評審組可對開發(fā)小組提問,提出建議和要求,展開討論。,會議結(jié)束時必須做出以下三個決策之一: 接受該產(chǎn)品,不需要做修改。 由于錯誤嚴重,拒絕接受。 暫時接受該產(chǎn)品,但需要對某一部分進行修改。 評審報告與記錄:對所提出的問題要進行記錄,并產(chǎn)生一個評審報告。,技術(shù)評審流程,同行評審(Peer Review),同行評審是一種特殊類型的技術(shù)評審。 由與工作產(chǎn)品開發(fā)人員具有同等背景和能

6、力的人員對工作產(chǎn)品進行技術(shù)評審,因此非常有利于發(fā)現(xiàn)工作產(chǎn)品中的問題。,代碼評審(Code Review),編碼階段的一種技術(shù)評審,由一組人員對程序進行閱讀和靜態(tài)分析,可以很有效地檢查程序代碼中的缺陷。 評審內(nèi)容:程序是否符合編碼規(guī)范,程序結(jié)構(gòu)是否合理,算法和程序邏輯是否正確,程序性能怎樣等。 很多程序邏輯錯誤很難通過測試發(fā)現(xiàn)。,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第三節(jié) 缺陷跟蹤,缺陷跟蹤是指從缺陷被發(fā)現(xiàn)開始到被改正為止的整個跟蹤流程。,缺陷跟蹤一般需要軟件工具支持。常用的工具有Bugzilla、ClearQuest

7、、Jira、TrackRecord 等。,缺陷跟蹤,缺陷跟蹤工具Bugzilla,Bugzilla是Mozilla公司提供的一個開源的缺陷跟蹤工具,在全世界擁有大量用戶。 它能夠為軟件組織建立一個完善的缺陷跟蹤體系,包括報告缺陷、查詢?nèi)毕萦涗洸a(chǎn)生報表、處理解決缺陷、管理員系統(tǒng)初始化和設(shè)置等。,Bugzilla的功能和特點:,基于Web方式運行,易于掌握。 缺陷從最初的報告到最后的關(guān)閉,都有詳細的操作記錄,確保了缺陷不會被忽略,并允許用戶在檢查缺陷狀態(tài)時獲取歷史記錄。 提供強大的查詢匹配能力,能根據(jù)各種條件組合進行缺陷查詢,并能夠記憶搜索條件。,當缺陷狀態(tài)發(fā)生改變時,會自動發(fā)送郵件通知相關(guān)責任

8、人。 自帶基于數(shù)據(jù)庫的報表生成功能,主要生成兩類圖表:基于表格的視圖和圖形視圖(條形圖、線圖、餅狀圖)。,Bugzilla的特點:,Bugzilla的基本操作說明,報告缺陷 分配缺陷 處理缺陷 驗證已解決的缺陷,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第四節(jié) 缺陷預(yù)防,優(yōu)點:主動 改進軟件過程,降低出錯幾率 降低質(zhì)量成本,實現(xiàn)項目效益,找到根本原因,消除根本原因,軟件缺陷原因分析方法,Step1:選擇缺陷數(shù)據(jù)。 對小項目,可選擇某一時期內(nèi)發(fā)現(xiàn)的所有缺陷。 對大項目,可選擇一個缺陷樣本集合。 Step2:分析缺陷的根本原因

9、 對缺陷逐個進行分析,常以會議的方式進行。 可對分析出的根本原因進行分類,例如: IBM:疏忽、培訓、通信失效、書寫錯誤 Motorola:開發(fā)階段相關(guān)、人員相關(guān)、項目相關(guān)、復(fù)審相關(guān),軟件缺陷原因分析方法,缺陷原因分析工具因果圖(魚骨圖),Step3:識別公共原因,制定改進措施。 在逐個分析了缺陷之后,還要對分析得到的根本原因進行綜合和歸納,識別導致缺陷產(chǎn)生的公共原因,并制定有關(guān)過程、技術(shù)和人員管理方面的改進措施。,軟件缺陷原因分析方法,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第五節(jié) 軟件質(zhì)量的常用度量,初期故障率:指軟

10、件在初期故障期(一般以軟件交付給用戶后的三個月內(nèi)為初期故障期)內(nèi)單位時間的故障數(shù)。 用來評價交付使用的軟件的質(zhì)量,預(yù)測什么時候軟件運行達到基本穩(wěn)定。 一般以每100小時的故障數(shù)為單位。,偶然故障率:指軟件在偶然故障期(一般以軟件交付給用戶后的4個月以后為偶然故障期)內(nèi)單位時間的故障數(shù)。 它用來度量軟件處于穩(wěn)定狀態(tài)下的質(zhì)量。 一般以每1000小時的故障數(shù)為單位。,軟件質(zhì)量的常用度量,平均失效前時間(Mean Time to Failure,MTTF):指軟件在失效前正常工作的平均統(tǒng)計時間。 用來度量軟件的可靠性。 平均修復(fù)時間(Mean Time to Repairation,MTTR):指軟件

11、失效后,使其恢復(fù)正常工作所需要的平均統(tǒng)計時間。 用來度量軟件的可維護性。,軟件質(zhì)量的常用度量,缺陷密度:指軟件單位數(shù)量的源代碼中隱藏的缺陷數(shù)量。 通常以每千行無注解源代碼為一個單位。,軟件質(zhì)量的常用度量,本章內(nèi)容提要,軟件質(zhì)量管理的基本概念 軟件質(zhì)量控制 缺陷跟蹤 缺陷預(yù)防 軟件質(zhì)量的常用度量 軟件項目質(zhì)量管理計劃,第六節(jié) 軟件項目質(zhì)量管理計劃,軟件項目質(zhì)量管理計劃一般應(yīng)滿足以下要求: 確定項目應(yīng)達到的質(zhì)量目標和所有特性的要求; 確定項目中的質(zhì)量活動和質(zhì)量控制程序; 確定項目采用的控制手段及合適的驗證手段和方法; 確定和準備質(zhì)量記錄。 制訂軟件項目質(zhì)量管理計劃的依據(jù)是企業(yè)的質(zhì)量體系和項目的特點。,改進軟件質(zhì)量的一些要求,軟件質(zhì)量活動

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論