軟件質(zhì)量保證課件

1、軟件質(zhì)量保證,SQA職責(zé)與活動(dòng),概要,質(zhì)量管理發(fā)展及發(fā)展方向 SQA職責(zé)及活動(dòng),質(zhì)量管理發(fā)展,質(zhì)量管理發(fā)展五個(gè)階段 質(zhì)量管理發(fā)展方向,質(zhì)量管理發(fā)展五個(gè)階段,1900,手工操作者,專職檢驗(yàn)員,1920,過(guò)程統(tǒng)計(jì)技術(shù),1931,全面質(zhì)量管理,1960,2000,以顧客為中心,階 段,時(shí)間,質(zhì)量管理發(fā)展趨勢(shì) 一個(gè)核心和兩個(gè)基本改變,核心：由對(duì)結(jié)果的檢驗(yàn)轉(zhuǎn)向?qū)^(guò)程精細(xì)的控制 改變： 管理范圍的改變 由針對(duì)以產(chǎn)品生產(chǎn)制造服務(wù)質(zhì)量管理擴(kuò)大到 行政部門工作質(zhì)量。 關(guān)注焦點(diǎn)的轉(zhuǎn)移 由面向以產(chǎn)品生存周期的 服務(wù)質(zhì)量管理轉(zhuǎn)向 顧客滿意為中心質(zhì)量管理。,軟件產(chǎn)業(yè)要經(jīng)歷三個(gè)不同時(shí)代,結(jié)構(gòu)化生產(chǎn)時(shí)代(70年代中期至90

2、年代中期)：結(jié)構(gòu)化分析；結(jié)構(gòu)化設(shè)計(jì)；結(jié)構(gòu)化程序設(shè)計(jì)；結(jié)構(gòu)化測(cè)試；結(jié)構(gòu)化審查與走查。 以過(guò)程為中心的時(shí)代(從80年代中期至2010年前后)：寓質(zhì)量和效率于生產(chǎn)過(guò)程之中；關(guān)于軟件過(guò)程的主要流派(ISO 9000，CMM/PSP/TSP)。 軟件工業(yè)化生產(chǎn)時(shí)代(1995年開(kāi)始)：基礎(chǔ)技術(shù)(軟件過(guò)程技術(shù)，面向?qū)ο蠹夹g(shù)，基于構(gòu)件的開(kāi)發(fā)技術(shù))；主要問(wèn)題(標(biāo)準(zhǔn)化，產(chǎn)業(yè)文化，政策法規(guī))；對(duì)前途的估計(jì)(我國(guó)2005年可以進(jìn)入軟件工業(yè)化生產(chǎn)時(shí)代)。,對(duì)于SQA一些誤解,誤解一、如果發(fā)布出去的軟件有質(zhì)量問(wèn)題，那是軟件測(cè)試人員的錯(cuò)；軟件的質(zhì)量是做出來(lái)的，而不是測(cè)出來(lái)的,對(duì)SQA與測(cè)試工作的誤解,誤解二、軟件測(cè)試技術(shù)要

3、求不高，比編程容易多了；很多人認(rèn)為軟件測(cè)試就是運(yùn)行一下軟件，然后看看結(jié)果對(duì)不對(duì)。但實(shí)際上，如何在有限的投入下，提高軟件測(cè)試的效率和產(chǎn)出是一件很見(jiàn)功底的事情。所以，好的測(cè)試人員不僅要掌握各種測(cè)試技術(shù)和測(cè)試工具，還要具備豐富的編程經(jīng)驗(yàn)和對(duì)BUG的敏感。另外，測(cè)試統(tǒng)計(jì)技術(shù)也是一項(xiàng)很特別的技術(shù),對(duì)SQA與測(cè)試工作的誤解,誤解五、設(shè)計(jì)-實(shí)現(xiàn)-測(cè)試，軟件測(cè)試是開(kāi)發(fā)后期的一個(gè)階段；實(shí)際上，軟件測(cè)試貫穿整個(gè)軟件產(chǎn)品生命期。一方面，軟件測(cè)試也要經(jīng)歷測(cè)試計(jì)劃、測(cè)試用例的設(shè)計(jì)和實(shí)現(xiàn)，以及測(cè)試運(yùn)行一系列的階段，因此，早在軟件需求階段，甚至更早，軟件測(cè)試的工作就要開(kāi)始了。另一方面，軟件測(cè)試越早進(jìn)行越好，因?yàn)锽UG越早發(fā)

4、現(xiàn)，BUG造成的影響和修改的代價(jià)就越小。而且，軟件測(cè)試并不僅僅針對(duì)程序，軟件的需求、設(shè)計(jì)等等也要被測(cè)試,對(duì)SQA與測(cè)試工作的誤解,誤解十、SQA工作就是做測(cè)試； 軟件測(cè)試是一種有效的提高軟件質(zhì)量的手段，但測(cè)試畢竟是一種事后的、檢驗(yàn)性的，如何在軟件生產(chǎn)過(guò)程中保證軟件過(guò)程的質(zhì)量和效率其實(shí)比單純的產(chǎn)品檢驗(yàn)具有更重要的意義。不斷地改進(jìn)我們的軟件過(guò)程是SQA的一項(xiàng)最重要的任務(wù)。,什么是軟件質(zhì)量,滿足明確聲明的功能和性能需求，明確文檔化的開(kāi)發(fā)過(guò)程以及專業(yè)人員開(kāi)發(fā)的軟件所具有的所有隱含特征（軟件工程實(shí)踐者理論） 理解： 軟件需求是質(zhì)量度量的基礎(chǔ)，與需求不符就是質(zhì)量不高 制訂的標(biāo)準(zhǔn)定義一組指導(dǎo)軟件開(kāi)發(fā)的標(biāo)準(zhǔn)，

5、如果不能按照這些準(zhǔn)則，就可能導(dǎo)致質(zhì)量不高 通常隱含需求是不被提及的（如軟件易維護(hù)性）, ANSI/IEEE 六個(gè)品質(zhì)要素 * 正確性（correctness）： 制作的功能，達(dá)到設(shè)計(jì)規(guī)范和滿足使用者需求的程度； * 可靠性（reliability）： 在規(guī)定期限和條件下，仍能維持其性能水平的程度； * 易使用性（usability）： 使用者學(xué)習(xí)、操作、準(zhǔn)備輸入、理解輸出所作努力的程度 * 效率（efficiency）： 軟件執(zhí)行某項(xiàng)功能所需的計(jì)算機(jī)資源（含時(shí)間）的有效程度 * 可維護(hù)性（maintainability）： 當(dāng)環(huán)境改變或軟件發(fā)生錯(cuò)誤時(shí)，執(zhí)行修改所做努力的程度 * 可移植性（po

6、rtability）： 從一個(gè)電腦系統(tǒng)或環(huán)境移到另一個(gè)電腦或環(huán)境的難易程度,軟件品質(zhì)特性,SQA活動(dòng)內(nèi)容,建立軟件質(zhì)量保證活動(dòng)的實(shí)體 制訂軟件質(zhì)量保證計(jì)劃 堅(jiān)持各階段的評(píng)審和審計(jì)，并跟蹤其結(jié)果作合適處理 監(jiān)控軟件產(chǎn)品的質(zhì)量 采集軟件質(zhì)量保證活動(dòng)的數(shù)據(jù) 度量軟件質(zhì)量保證活動(dòng),軟件品保活動(dòng),技術(shù)方法的使用 使用良好的開(kāi)發(fā)技術(shù)，以確保開(kāi)發(fā)軟件品質(zhì) Object-Oriented, Structure Design 清楚而文件化的需求規(guī)格或外部功能規(guī)格 訓(xùn)練良好，且技術(shù)熟練的人員 良好的項(xiàng)目管理技術(shù) 正式技術(shù)復(fù)核的使用 在軟件開(kāi)發(fā)各階段中，有效的審查各項(xiàng)開(kāi)發(fā)文件 確保設(shè)計(jì)的正確性與有效性 確保各組件間

7、設(shè)計(jì)的一致性 溝通各部門間的想法,軟體品?；顒?dòng)（續(xù)）,軟件測(cè)試 標(biāo)準(zhǔn)的實(shí)行 包含外部標(biāo)準(zhǔn)與內(nèi)部標(biāo)準(zhǔn) 開(kāi)發(fā)標(biāo)準(zhǔn)、文件標(biāo)準(zhǔn)、程序撰寫(xiě)標(biāo)準(zhǔn)、測(cè)試執(zhí)行準(zhǔn)則. 標(biāo)準(zhǔn)的改進(jìn)是軟件業(yè)矯正與預(yù)防措施之重要項(xiàng)目 變動(dòng)(Change)的控制 建構(gòu)管理、變更管制 度量(measurement) 記錄及報(bào)告,各階段活動(dòng)監(jiān)督、審核和跟蹤,評(píng)審：活動(dòng) 里程碑活動(dòng)評(píng)審 基線評(píng)審 SCM評(píng)審 SQA工作評(píng)審 審計(jì)：工作 基線審計(jì) SQA審計(jì) 有背離之處，則對(duì)其進(jìn)行標(biāo)識(shí)、記錄、并跟蹤直至其符合。,最有效的軟件品保工具 有了相當(dāng)好的軟件品保人員、品保計(jì)劃之后，尚必須具有最有效的工具，才能將整個(gè)軟件品保工作執(zhí)行得相當(dāng)透徹。 甚么是

8、最有效的品保工具？答案是Peer Review 。 在所有的發(fā)展及維護(hù)過(guò)程中，Peer Review能找出相當(dāng)多的問(wèn)題。如何找出？茲分別敘述如下： (1) 在需求分析階段：藉由需求審查，以確定需求是否正確地定義。 (2) 在設(shè)計(jì)階段：藉由審查程序架構(gòu)及細(xì)部設(shè)計(jì)與PDL。 (3) 在程序撰寫(xiě)階段：藉由審查Source Code。 (4) 在軟件測(cè)試階段：藉由審查所有的測(cè)試文件。 (5) 在軟件維護(hù)階段：藉由審查所有的文件、Code、修改。 Peer Review的指引(Guidelines)包括： (1) Review 時(shí)包括越少人越好，而且成員越早通知越好。 (2) Review必須常舉行，而

9、且必須包括很小部份的工作。 (3) Review必須強(qiáng)調(diào)效率及注重所Review 的材料內(nèi)容，其必須是該階段所能產(chǎn)生 的最佳產(chǎn)品。 (4) Review 最好能有4小時(shí)以上的時(shí)間來(lái)閱讀數(shù)據(jù)。 (5) Review 最好能有Lead Engineer以上的人參加，以知道問(wèn)題所在。,17,軟件正式技術(shù)評(píng)審(review)指導(dǎo),監(jiān)控軟件產(chǎn)品質(zhì)量,對(duì)軟件產(chǎn)品的驗(yàn)收 把握采購(gòu)軟件的質(zhì)量 監(jiān)控分承包商的軟件質(zhì)量保證工作,收集項(xiàng)目各個(gè)階段數(shù)據(jù),記錄不協(xié)調(diào)事項(xiàng) 跟蹤不協(xié)調(diào)事項(xiàng)直至解決 收集各階段的評(píng)審和審計(jì)情況,缺陷密度 (Defect Density),此項(xiàng)因素可以提供來(lái)作作為軟體設(shè)計(jì)與程式製作品質(zhì)的一項(xiàng)數(shù)據(jù)。 其輸入?yún)?shù)直接來(lái)自設(shè)計(jì)與Code Inspection的過(guò)程，其中缺陷(Defects)可能為需求、設(shè)計(jì)、程式製作等種類。其運(yùn)算式為 缺陷總數(shù) of 單元,4 5 6 7 . 14 15 16 17 18 19 20 21,0.5,1.5,1.0,CDR,Defect / Unit,Contract