第19章：軟件質(zhì)量保證

第19章軟件質(zhì)量保證19.1軟件質(zhì)量與SQA19.2軟件復(fù)審19.3正式的技術(shù)復(fù)審19.4基于統(tǒng)計(jì)的質(zhì)量保證19.5軟件可靠性19.6SQA計(jì)劃19.7小結(jié)16.1軟件質(zhì)量與SQA16.1.1軟件質(zhì)量在ANSI/IEEE的729-1983號(hào)標(biāo)準(zhǔn)中定義軟件質(zhì)量為：“與軟件產(chǎn)品滿足規(guī)定和隱含需求的能力有關(guān)的全體特征(或特性)”。為滿足軟件的各項(xiàng)規(guī)定的或隱含的功能、性能需求，符合文檔化開發(fā)標(biāo)準(zhǔn)，就需要相應(yīng)地設(shè)計(jì)出一些質(zhì)量特性及其組合——質(zhì)量目標(biāo)，作為在軟件開發(fā)與維護(hù)中的重要考慮因素。如果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，則這個(gè)軟件產(chǎn)品的質(zhì)量就是高的。這些被定義出來的特性及其組合就稱之為軟件的“質(zhì)量目標(biāo)”。從上述軟件質(zhì)量的定義中，反映出了以下三個(gè)方面的問題。(1)軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。(2)軟件人員必須遵循軟件過程規(guī)范，用工程化的方法來開發(fā)軟件。如果不遵守這些規(guī)程，軟件質(zhì)量就沒有保證。(3)往往會(huì)有一些隱含的需求沒有明確地提出來。如果軟件只是滿足那些規(guī)定的需求而不可能滿足那些可能存在的隱含需求，軟件質(zhì)量也不能保證。軟件質(zhì)量是各種特性的復(fù)雜組合，它隨著應(yīng)用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。在計(jì)算機(jī)發(fā)展的早期(20世紀(jì)50和60年代)，軟件質(zhì)量保證工作曾經(jīng)只由程序員來承擔(dān)。20世紀(jì)70年代，美國軍方在軟件開發(fā)合同中首先提出了軟件質(zhì)量保證的標(biāo)準(zhǔn)，提出了軟件質(zhì)量保證活動(dòng)的定義是為了保證軟件質(zhì)量而必須的“有計(jì)劃的和系統(tǒng)化的行動(dòng)模式”這一觀點(diǎn)。這一定義的含義是要求在一個(gè)組織中應(yīng)當(dāng)由多個(gè)機(jī)構(gòu)共同協(xié)作，承擔(dān)保證軟件質(zhì)量的責(zé)任。包括軟件工程師、項(xiàng)目管理者、客戶、銷售人員和SQA小組的人員。SQA小組是軟件開發(fā)組織中獨(dú)立于任何項(xiàng)目組的專職品質(zhì)保證組織。他們以客戶的觀點(diǎn)來看待軟件，通過自己的工作來回答軟件是否滿足各項(xiàng)質(zhì)量指標(biāo)、軟件開發(fā)是否按照預(yù)先設(shè)定的標(biāo)準(zhǔn)進(jìn)行、作為SQA活動(dòng)一部分的技術(shù)規(guī)程是否恰當(dāng)?shù)匕l(fā)揮了作用等問題。換句話說，SQA針對(duì)工作過程與標(biāo)準(zhǔn)的符合性、工作產(chǎn)品與標(biāo)準(zhǔn)的符合性進(jìn)行審核與審查。19.1.2SQA活動(dòng)軟件質(zhì)量保證活動(dòng)由各種任務(wù)構(gòu)成。這些任務(wù)分別和從事技術(shù)工作的軟件工程師和負(fù)責(zé)對(duì)質(zhì)量保證活動(dòng)進(jìn)行計(jì)劃、監(jiān)督、記錄、分析、報(bào)告工作的專職SQA小組成員相關(guān)。軟件工程師通過采用可靠的技術(shù)方法和措施，進(jìn)行正式的技術(shù)復(fù)審，執(zhí)行計(jì)劃周密的軟件測(cè)試來考慮軟件質(zhì)量問題并保證軟件質(zhì)量；SQA小組的職責(zé)是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。SEI推薦了一組有關(guān)軟件質(zhì)量保證活動(dòng)中的計(jì)劃、監(jiān)督、記錄分析及報(bào)告的SQA活動(dòng)。這些活動(dòng)由一個(gè)獨(dú)立的SQA小組執(zhí)行。按照SEI的建議，具體的SQA活動(dòng)應(yīng)當(dāng)包括：(1)為項(xiàng)目準(zhǔn)備SQA計(jì)劃：該計(jì)劃在制定項(xiàng)目開發(fā)計(jì)劃時(shí)制訂，由所有對(duì)質(zhì)量感興趣的相關(guān)部門復(fù)審。該計(jì)劃將控制由軟件工程小組和SQA小組執(zhí)行的軟件質(zhì)量保證活動(dòng)。在SQA計(jì)劃中，應(yīng)當(dāng)包含：需要進(jìn)行的評(píng)價(jià)；需要進(jìn)行的審查和復(fù)審；項(xiàng)目可以采用的標(biāo)準(zhǔn)；錯(cuò)誤報(bào)告和跟蹤過程；由SQA小組產(chǎn)生的文檔目錄；為軟件項(xiàng)目組提供的反饋數(shù)據(jù)種類。(2)參與開發(fā)該項(xiàng)目的軟件過程：軟件工程小組為將要進(jìn)行的工作選擇一個(gè)工程過程。SQA小組將復(fù)審過程說明，以保證該過程與組織政策、內(nèi)部軟件標(biāo)準(zhǔn)、外部標(biāo)準(zhǔn)以及軟件開發(fā)計(jì)劃的其他部分相符合。(3)復(fù)審各項(xiàng)軟件工程活動(dòng)：對(duì)工程活動(dòng)是否符合定義好的軟件工程過程進(jìn)行核實(shí)。SQA小組識(shí)別、記錄和跟蹤實(shí)際工作與已定義過程之間的偏差，提出報(bào)告要求改正的地方并對(duì)是否已經(jīng)改正進(jìn)行跟蹤與核實(shí)。(4)審查指定的軟件工作產(chǎn)品，對(duì)其是否符合定義好的軟件工程過程中的相應(yīng)部分進(jìn)行核實(shí)。SQA小組要對(duì)選出的產(chǎn)品進(jìn)行復(fù)審，識(shí)別、記錄和跟蹤產(chǎn)品與過程規(guī)定的偏差，并對(duì)是否已經(jīng)改正進(jìn)行跟蹤核實(shí)。定期地將工作結(jié)果向項(xiàng)目管理者報(bào)告。(5)確保軟件工作及工作產(chǎn)品中的偏差已記錄在案，并按照預(yù)定規(guī)程進(jìn)行處理。偏差可能出現(xiàn)在項(xiàng)目計(jì)劃、過程描述、采用的標(biāo)準(zhǔn)或技術(shù)工作產(chǎn)品中。(6)記錄所有的不符合部分，并報(bào)告給高級(jí)管理者，對(duì)不符合部分進(jìn)行跟蹤，直到問題得到解決。此外，SQA小組還要協(xié)調(diào)變更的控制和管理，并協(xié)助收集項(xiàng)目度量信息。16.2軟件復(fù)審19.2.1軟件復(fù)審軟件復(fù)審是軟件工程過程中濾除缺陷的“過濾器”。在軟件項(xiàng)目開發(fā)過程中的多個(gè)不同的點(diǎn)上，軟件復(fù)審活動(dòng)能夠起到及早發(fā)現(xiàn)錯(cuò)誤進(jìn)而引發(fā)排錯(cuò)活動(dòng)的作用。軟件復(fù)審的目的是盡可能多地發(fā)現(xiàn)被復(fù)審對(duì)象中的缺陷，起到“凈化”工作產(chǎn)品的作用。由于我們發(fā)現(xiàn)別人生產(chǎn)的工作產(chǎn)品中的缺陷比發(fā)現(xiàn)自己的缺陷要容易，所以復(fù)審應(yīng)當(dāng)在不同的工程師之間進(jìn)行。任何一次復(fù)審都是借助人的差異性來達(dá)到目標(biāo)的活動(dòng)，它的目標(biāo)包括：(1)指出一個(gè)人或一個(gè)小組生產(chǎn)的產(chǎn)品所需進(jìn)行的改進(jìn)。(2)確定被審核產(chǎn)品中不需要或者不希望改進(jìn)的部分。(3)得到與未復(fù)審時(shí)相比更加一致，至少更可預(yù)測(cè)的技術(shù)工作的質(zhì)量，從而使得技術(shù)工作更可管理。復(fù)審的方式很多，包括非正式的復(fù)審、正式的同行評(píng)審、管理復(fù)審等等。19.2.2軟件缺陷對(duì)成本的影響在軟件工程活動(dòng)中，“缺陷”是指在軟件交付給最終用戶后發(fā)現(xiàn)的質(zhì)量問題；而“錯(cuò)誤”描述在軟件交付前由軟件工程師發(fā)現(xiàn)的質(zhì)量問題。很明顯，缺陷帶來的危害遠(yuǎn)大于“錯(cuò)誤”帶來的影響。因此，正式技術(shù)復(fù)審的主要目標(biāo)就是在復(fù)審過程中發(fā)現(xiàn)錯(cuò)誤，以便潛在的缺陷在交付之前變成“錯(cuò)誤”并得到糾正。正式技術(shù)復(fù)審的明顯優(yōu)點(diǎn)就是能夠較早發(fā)現(xiàn)錯(cuò)誤，防止錯(cuò)誤傳播到軟件過程的后繼階段?！氨M早”發(fā)現(xiàn)錯(cuò)誤是我們的追求，因?yàn)橥瑯拥腻e(cuò)誤對(duì)成本和工期產(chǎn)生的影響與發(fā)現(xiàn)錯(cuò)誤、改正錯(cuò)誤的時(shí)間是密切相關(guān)的。大量的研究表明，設(shè)計(jì)活動(dòng)引入的錯(cuò)誤占軟件過程中出現(xiàn)的所有錯(cuò)誤和最終缺陷數(shù)量的50%～70%。而近期的研究表明，正式的技術(shù)復(fù)審在發(fā)現(xiàn)設(shè)計(jì)錯(cuò)誤方面有最高達(dá)到75%的有效性。由于能夠通過復(fù)審檢測(cè)和排除大量的設(shè)計(jì)錯(cuò)誤，復(fù)審過程將可望極大地降低后繼開發(fā)和維護(hù)階段的工作成本。根據(jù)從多個(gè)大型項(xiàng)目中采集的數(shù)據(jù)表明，假如在設(shè)計(jì)階段發(fā)現(xiàn)的一個(gè)錯(cuò)誤的改正成本是1個(gè)貨幣單位，那么在測(cè)試之前發(fā)現(xiàn)的一個(gè)錯(cuò)誤的改正成本就是6.5個(gè)貨幣單位，在測(cè)試時(shí)發(fā)現(xiàn)一個(gè)錯(cuò)誤的改正成本變成15個(gè)貨幣單位，而在發(fā)布之后，改進(jìn)一處缺陷的成本達(dá)到60～100個(gè)貨幣單位。因此，盡可能早地發(fā)現(xiàn)錯(cuò)誤，是降低軟件錯(cuò)誤/缺陷對(duì)工程成本影響的有效途徑。19.2.3缺陷的放大和消除可以用“缺陷放大模型”來說明及時(shí)的復(fù)審在軟件工程中的作用(如圖19.1所示)。圖中，方塊表示一個(gè)開發(fā)步驟，可能因疏忽而產(chǎn)生錯(cuò)誤。復(fù)審過程可能沒有完全發(fā)現(xiàn)來自此步驟之前的和新發(fā)生的所有錯(cuò)誤。從而可能在本階段“繼承”了一些錯(cuò)誤，并將一部分錯(cuò)誤引入下一階段。其中，一部分來自前一階段的錯(cuò)誤可能會(huì)誤導(dǎo)本階段的工作，導(dǎo)致在錯(cuò)誤的基礎(chǔ)上產(chǎn)生更多的錯(cuò)誤，形成錯(cuò)誤的“放大”效應(yīng)。圖19.1缺陷的放大模型圖19.2是一個(gè)沒有進(jìn)行技術(shù)復(fù)審的軟件開發(fā)過程中缺陷放大的例子。樂觀地設(shè)想，在每一個(gè)測(cè)試步驟都能夠發(fā)現(xiàn)并改正50%的輸入錯(cuò)誤，而又不引入新的錯(cuò)誤。在圖中明顯地看到，最初在概要設(shè)計(jì)階段產(chǎn)生的10個(gè)錯(cuò)誤，到集成測(cè)試之前已經(jīng)放大成為94個(gè)。12個(gè)隱藏的缺陷將隨著軟件的發(fā)布擴(kuò)散到用戶處。表16.1是無復(fù)審情況下缺陷放大數(shù)據(jù)及因此增加的成本數(shù)據(jù)。圖19.2缺陷的放大——無復(fù)審表19.1無復(fù)審情況下軟件缺陷對(duì)成本的影響錯(cuò)誤發(fā)現(xiàn)時(shí)機(jī)缺陷數(shù)量成本單位成本總計(jì)測(cè)試之前226.5143測(cè)試期間82151230發(fā)布之后1267804缺陷總成本

2177從圖19.3中可以看到，只要在每個(gè)工程階段都進(jìn)行復(fù)審工作，就能夠有效地遏制缺陷放大的勢(shì)頭，從而減少缺陷對(duì)成本的影響。在概要設(shè)計(jì)階段同樣是10個(gè)錯(cuò)誤，到集成測(cè)試時(shí)僅擴(kuò)展為24個(gè)，最終輸出到用戶處的缺陷只有三個(gè)。表19.2是有復(fù)審情況下缺陷數(shù)據(jù)及因此增加的成本數(shù)據(jù)。從上例中能夠清晰地看出，實(shí)行復(fù)審能夠及早地發(fā)現(xiàn)大部分錯(cuò)誤，極大地減少交付產(chǎn)品中的缺陷數(shù)，降低因修正缺陷帶來的成本。當(dāng)然，為了進(jìn)行復(fù)審，開發(fā)人員也必須投入工作量，也就是說，組織必須為復(fù)審支付成本。但復(fù)審增加的成本和因進(jìn)行了復(fù)審而降低的糾正錯(cuò)誤和缺陷的成本相比，是相當(dāng)?shù)偷?。因此，軟件開發(fā)組織應(yīng)當(dāng)在各個(gè)工作階段上組織進(jìn)行有效的復(fù)審，以便消除缺陷，減少缺陷成本，保證軟件質(zhì)量。圖19.3缺陷的放大——有復(fù)審表19.2有復(fù)審情況下軟件缺陷對(duì)成本的影響錯(cuò)誤發(fā)現(xiàn)時(shí)機(jī)缺陷數(shù)量成本單位成本總計(jì)設(shè)計(jì)期間221.533測(cè)試之前366.5234測(cè)試期間1515315發(fā)布之后367201缺陷總成本

78319.3正式的技術(shù)復(fù)審正式技術(shù)復(fù)審(FTR)是一種由技術(shù)工程師進(jìn)行的軟件質(zhì)量保證活動(dòng)。FTR的目標(biāo)是：(1)在軟件的任何一種表示形式中發(fā)現(xiàn)功能、邏輯或?qū)崿F(xiàn)上的錯(cuò)誤。(2)證實(shí)經(jīng)過復(fù)審的軟件的確滿足需求。(3)保證軟件的表示符合預(yù)定義的標(biāo)準(zhǔn)。(4)得到一種以一致的方式開發(fā)的軟件。(5)使項(xiàng)目更加容易管理。因?yàn)镕TR的進(jìn)行使大量人員對(duì)軟件系統(tǒng)中原本并不熟悉的部分更加了解，因此，F(xiàn)TR還起到了提高項(xiàng)目連續(xù)性和培訓(xùn)后備人員的作用。FTR實(shí)際上是一類復(fù)審方式，包括“走查”(Walkthrough)、“審查”(Inspection)、“輪查”(RoundRobinReview)以及其他軟件小組的技術(shù)評(píng)估。每次的FTR都以會(huì)議的形式進(jìn)行，只有經(jīng)過適當(dāng)?shù)赜?jì)劃、控制和相關(guān)人員的積極參與，F(xiàn)TR才能獲得成功。19.3.1復(fù)審會(huì)議的組織從保證會(huì)議效果出發(fā)，不論進(jìn)行什么形式的FTR活動(dòng)，會(huì)議的規(guī)模都不宜過大，控制在3～5人較好；每個(gè)參會(huì)人員都要提前進(jìn)行準(zhǔn)備，但是復(fù)審準(zhǔn)備工作占用的工作時(shí)間應(yīng)當(dāng)少于兩小時(shí)；會(huì)議的時(shí)間不宜長，控制在兩個(gè)小時(shí)之內(nèi)?？紤]到這樣的約束，每次復(fù)審的對(duì)象顯然應(yīng)當(dāng)只是整個(gè)軟件中的某個(gè)較小的特定部分。不要試圖一次復(fù)查整個(gè)設(shè)計(jì)，而要對(duì)每個(gè)模塊或者一小組模塊進(jìn)行復(fù)審走查。經(jīng)驗(yàn)證明，當(dāng)一次FTR關(guān)注的范圍較小時(shí)，發(fā)現(xiàn)錯(cuò)誤的可能性更大一些。FTR的焦點(diǎn)是某個(gè)工作產(chǎn)品，比如一部分需求規(guī)約，一個(gè)模塊的詳細(xì)設(shè)計(jì)，一個(gè)模塊的源代碼清單等等。負(fù)責(zé)生產(chǎn)這個(gè)產(chǎn)品的人通知“復(fù)審責(zé)任人”產(chǎn)品已經(jīng)完成，需要復(fù)審。復(fù)審責(zé)任人對(duì)工作產(chǎn)品的完成情況進(jìn)行評(píng)估，當(dāng)確認(rèn)已經(jīng)具備復(fù)審條件后，準(zhǔn)備產(chǎn)品副本，發(fā)放給預(yù)定要參加復(fù)審的復(fù)審者。復(fù)審者花1～2小時(shí)進(jìn)行準(zhǔn)備。通常在第二天召開復(fù)審會(huì)議。復(fù)審會(huì)議由復(fù)審責(zé)任人主持，產(chǎn)品生產(chǎn)者和所有的復(fù)審者參加，并安排專門的記錄員。產(chǎn)品生產(chǎn)者在會(huì)議上要“遍歷”工作產(chǎn)品并進(jìn)行講解，復(fù)審者則根據(jù)各自的準(zhǔn)備提出問題。當(dāng)發(fā)現(xiàn)錯(cuò)誤和問題時(shí)，記錄員將逐一進(jìn)行記錄。在復(fù)審結(jié)束時(shí)，必須做出復(fù)審結(jié)論。結(jié)論只能是下列三種之一：(1)工作產(chǎn)品可以不經(jīng)修改地被接收。(2)由于存在嚴(yán)重錯(cuò)誤，產(chǎn)品被否決(錯(cuò)誤改正后必須重新復(fù)審)。(3)暫時(shí)接收工作產(chǎn)品(發(fā)現(xiàn)了輕微錯(cuò)誤需要改正，但改正后無需再次評(píng)審)。參與復(fù)審的所有人員，都必須在結(jié)論上簽字以表示他們參加了本次FTR，并同意復(fù)審小組的結(jié)論。19.3.2復(fù)審報(bào)告和記錄保存在FTR期間，一名復(fù)審者(記錄員)主動(dòng)記錄所有被提出來的問題。在會(huì)議結(jié)束時(shí)對(duì)這些問題進(jìn)行小結(jié)，并形成一份“復(fù)審問題列表”。此外還要形成一份簡單的“復(fù)審總結(jié)報(bào)告”。復(fù)審總結(jié)報(bào)告中將闡明如下問題：復(fù)審對(duì)象是什么；有哪些人參與復(fù)審；發(fā)現(xiàn)了什么，結(jié)論是什么。復(fù)審報(bào)告是項(xiàng)目歷史記錄的一部分，可以分發(fā)給項(xiàng)目負(fù)責(zé)人和其他感興趣的復(fù)審參與方。復(fù)審問題列表有兩個(gè)作用，首先是標(biāo)識(shí)產(chǎn)品中的問題區(qū)域，其次將被用作指導(dǎo)生產(chǎn)者對(duì)產(chǎn)品進(jìn)行改進(jìn)的“行動(dòng)條目”。在復(fù)審總結(jié)報(bào)告中，復(fù)審問題列表應(yīng)當(dāng)作為附件。SQA人員必須參與復(fù)審。他們一方面觀察復(fù)審過程的合理性，另一方面將會(huì)在今后對(duì)問題列表中各個(gè)問題的改正情況進(jìn)行跟蹤、檢查并通報(bào)缺陷修改情況，直到復(fù)審?fù)ㄟ^或問題徹底解決。19.3.3復(fù)審指南不受控制的錯(cuò)誤的復(fù)審，比沒有復(fù)審更加糟糕。所以在進(jìn)行正式的復(fù)審之前必須制定復(fù)審指南并分發(fā)給所有的復(fù)審參加者，得到大家的認(rèn)可后，才能依照指南進(jìn)行復(fù)審。正式技術(shù)復(fù)審指南的最小集合如下：(1)復(fù)審對(duì)象是產(chǎn)品，而不是產(chǎn)品生產(chǎn)者。復(fù)審會(huì)議的氣氛應(yīng)當(dāng)是輕松的和建設(shè)性的，不要試圖貶低或者羞辱別人。通常，有管理職權(quán)的成員不宜作為復(fù)審者參加會(huì)議。(2)制訂并嚴(yán)格遵守議程。FTR會(huì)議必須保證按照計(jì)劃進(jìn)行，不要離題。(3)鼓勵(lì)復(fù)審者提出問題，但限制爭論和辯駁。有爭議的問題記錄在案，事后解決。(4)復(fù)審是以“發(fā)現(xiàn)問題”為宗旨的。問題的解決通常由生產(chǎn)者自己或者在別人的幫助下解決。所以不要試圖在FTR會(huì)議上解決所有問題。(5)必須設(shè)置專門的記錄員，做好會(huì)議記錄。(6)為保證FTR有實(shí)效，堅(jiān)持要求與會(huì)者事先做好準(zhǔn)備，提交書面的評(píng)審意見，并要限制與會(huì)人數(shù)，將人數(shù)保持在最小的必須值上。(7)組織應(yīng)當(dāng)為每類要復(fù)審的產(chǎn)品(如各種計(jì)劃、需求分析、設(shè)計(jì)、編碼、測(cè)試用例)建立檢查表，幫助復(fù)審主持者組織FTR會(huì)議，并幫助每個(gè)復(fù)審者都能夠把注意力放在對(duì)具體產(chǎn)品來說最為關(guān)鍵的問題上。(8)為FTR分配足夠的資源和時(shí)間，并且要為復(fù)審結(jié)果所必然導(dǎo)致的產(chǎn)品修改活動(dòng)分配時(shí)間。(9)所有參與復(fù)審的人，都應(yīng)當(dāng)具備進(jìn)行FTR的技能，接受過相關(guān)的培訓(xùn)。(10)復(fù)審以前所作的復(fù)審，總結(jié)復(fù)審工作經(jīng)驗(yàn)，不斷提高復(fù)審水平。19.4基于統(tǒng)計(jì)的質(zhì)量保證有經(jīng)驗(yàn)的業(yè)界人士都同意下面的觀點(diǎn)：大多數(shù)真正麻煩的缺陷都可以追溯到數(shù)量相對(duì)有限的根本原因上。對(duì)一段較長時(shí)間內(nèi)發(fā)現(xiàn)的軟件缺陷進(jìn)行收集、統(tǒng)計(jì)，并利用統(tǒng)計(jì)規(guī)律對(duì)大量的缺陷數(shù)據(jù)進(jìn)行深入的分析，有助于我們逐漸發(fā)現(xiàn)導(dǎo)致大部分缺陷的根本原因，從而能夠?qū)⑺鼈兎蛛x出來，集中力量予以解決。這樣，就可以在SQA活動(dòng)中做到“將時(shí)間集中用在真正重要的地方”，有針對(duì)性地進(jìn)行質(zhì)量保證活動(dòng)。這種方法稱之為“基于統(tǒng)計(jì)的質(zhì)量保證”?；诮y(tǒng)計(jì)的SQA包括以下的步驟：(1)收集軟件缺陷信息并進(jìn)行分類。(2)嘗試對(duì)每個(gè)缺陷的成因進(jìn)行追溯。(3)通過追溯，將少數(shù)最重要的缺陷成因分離出來。(4)針對(duì)分離出的重要的缺陷成因，進(jìn)行有針對(duì)性的改進(jìn)活動(dòng)。假如一個(gè)軟件開發(fā)組織在一年內(nèi)利用復(fù)審、測(cè)試、用戶反饋等途徑搜集到了有關(guān)自身產(chǎn)品的錯(cuò)誤/缺陷信息，盡管發(fā)現(xiàn)的錯(cuò)誤/缺陷數(shù)以百計(jì)，但是經(jīng)過歸類，所有的錯(cuò)誤/缺陷的原因都可以歸為下列原因中的一個(gè)或幾個(gè)：IES：說明不完整或說明錯(cuò)誤；MCC：與客戶通信中產(chǎn)生誤解；IDS：故意與說明偏離；VPS：違犯編程標(biāo)準(zhǔn)；EDR：數(shù)據(jù)表示錯(cuò)誤；IMI：模塊接口不一致；EDL：設(shè)計(jì)邏輯有錯(cuò)；IET：不完整的或錯(cuò)誤的測(cè)試；IID：不準(zhǔn)確或不完整的文檔；PLT：將設(shè)計(jì)翻譯成預(yù)定語言時(shí)的錯(cuò)誤；HCI：不清晰或不一致的人機(jī)界面；MIS：雜項(xiàng)。設(shè)計(jì)一張表格，將各類錯(cuò)誤/缺陷的統(tǒng)計(jì)數(shù)據(jù)和它們各自在所有錯(cuò)誤/缺陷中所占的比例計(jì)算出來，以此數(shù)值為鍵值進(jìn)行降序排序，造成所有錯(cuò)誤/缺陷的重要原因就能夠十分清晰地凸現(xiàn)出來。表16.3中顯示IES、MCC和EDR是導(dǎo)致發(fā)生53%的錯(cuò)誤/缺陷的“少數(shù)重要原因”。同時(shí)可以看出，如果我們將注意力集中到嚴(yán)重錯(cuò)誤的成因上，那么應(yīng)該將IES、EDR、PLT和EDL作為“少數(shù)重要原因”。一旦確定了“少數(shù)重要原因”，開發(fā)組織就可以采取改進(jìn)行動(dòng)。例如，為了改正MCC錯(cuò)誤，開發(fā)者可以采用更便于理解的軟件說明技術(shù)，提高和用戶通信交流的質(zhì)量。為了改正EDR導(dǎo)致的錯(cuò)誤，可以使用CASE工具進(jìn)行數(shù)據(jù)建模，并進(jìn)行更加嚴(yán)格的數(shù)據(jù)設(shè)計(jì)復(fù)審。當(dāng)導(dǎo)致錯(cuò)誤和缺陷的少數(shù)重要原因被識(shí)別、糾正后，一些原來不那么重要的原因會(huì)成為統(tǒng)計(jì)數(shù)據(jù)表中新的“少數(shù)重要原因”。這樣，SQA活動(dòng)能夠始終針對(duì)當(dāng)前導(dǎo)致錯(cuò)誤和缺陷的主要原因展開工作，取得事半功倍的效果。這也就是基于統(tǒng)計(jì)的質(zhì)量保證活動(dòng)價(jià)值之所在。表19.3統(tǒng)計(jì)SQA的數(shù)據(jù)收集與分類錯(cuò)誤類別錯(cuò)誤總計(jì)嚴(yán)重錯(cuò)誤一般錯(cuò)誤輕微錯(cuò)誤數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比IES20522%3427%6818%10324%MCC15617%129%6818%7617%IDS485%11%246%235%VPS253%00%154%102%EDR13014%2620%6818%368IMI586%97%185%317%EDL455%1411%123%194%IET9510%129%359%4811%IID364%22%205%143%PLT606%1512%195%266%HCI283%32%174%82%MIS566%00%154%419%統(tǒng)計(jì)值942100%128100%379100%435100%19.5軟件可靠性19.5.1可靠性和可用性軟件可靠性的含義是：“程序在給定的時(shí)間間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功地運(yùn)行的概率”。在這個(gè)定義中包含的隨機(jī)變量是“時(shí)間間隔”。顯然隨著運(yùn)行時(shí)間的增加，運(yùn)行時(shí)遇到程序故障的概率也將增加，即可靠性隨著時(shí)間間隔的加大而減小。除可靠性之外，用戶也非常關(guān)心軟件系統(tǒng)可以使用的程度。一般來說，對(duì)于任何一個(gè)可以修復(fù)的系統(tǒng)，都應(yīng)當(dāng)同時(shí)使用可靠性和可用性來衡量它的優(yōu)劣。軟件可用性的一個(gè)定義是：“程序在給定的時(shí)間點(diǎn)，按照規(guī)格說明書的規(guī)定成功地運(yùn)行的概率”?？煽啃院涂捎眯灾g的主要差別在于：可靠性意味著在0～t這段時(shí)間間隔內(nèi)系統(tǒng)沒有失效；而可用性只是意味著在時(shí)刻t系統(tǒng)是正常運(yùn)行的。因此，如果在時(shí)刻t系統(tǒng)是可用的，則包括下述種種可能：在0～t這段時(shí)間里，系統(tǒng)一直沒有失效；在這段時(shí)間里失效了一次，但是又修復(fù)了；在這段時(shí)間里失效了兩次、又修復(fù)了兩次......如果在一段時(shí)間里，軟件系統(tǒng)故障停機(jī)時(shí)間分別為td1，td2，td3......正常運(yùn)行時(shí)間分別為tu1，tu2，tu3......則系統(tǒng)的穩(wěn)態(tài)可用性為(19.1)其中，Tup=∑tui，Tdown=∑tdi。如果引進(jìn)系統(tǒng)平均無故障時(shí)間MTTF和系統(tǒng)平均維修時(shí)間MTTR的概念，那么，軟件系統(tǒng)的穩(wěn)態(tài)可用性可以表示為平均維修時(shí)間MTTR是修復(fù)一個(gè)故障平均需要的時(shí)間，它取決于維護(hù)人員的技術(shù)水平和對(duì)系統(tǒng)的熟悉程度，也和系統(tǒng)的可維護(hù)性有重要關(guān)系。平均無故障時(shí)間MTTF是系統(tǒng)按照規(guī)格說明書的規(guī)定成功運(yùn)行的平均時(shí)間，它主要取決于系統(tǒng)中潛伏的缺陷數(shù)目，因此和測(cè)試的關(guān)系十分密切。(19.2)為了直觀地度量軟件的可靠性，還可以采用“平均失效間隔時(shí)間”MTBF。MTBF=MTTF+MTTR(19.3)19.5.2平均無故障運(yùn)行時(shí)間的估算軟件的平均無故障運(yùn)行時(shí)間MTTF是一個(gè)重要的質(zhì)量指標(biāo)，用戶往往把MTTF作為對(duì)軟件的一種性能需求提出來。為滿足用戶的需求，開發(fā)組織就應(yīng)當(dāng)在交付產(chǎn)品時(shí)估算出產(chǎn)品的MTTF值。為了估算MTTF，首先引入一組符號(hào)：Et ：測(cè)試之前程序中的缺陷總數(shù)；It ：用機(jī)器指令總數(shù)衡量的程序長度；τ ：測(cè)試(包括調(diào)試)時(shí)間；Ed(τ) ：在0～τ時(shí)間內(nèi)發(fā)現(xiàn)的錯(cuò)誤總數(shù)；Ec(τ) ：在0～τ時(shí)間內(nèi)改正的錯(cuò)誤總數(shù)；Er ：在0～τ時(shí)間后剩余的缺陷數(shù)。建立一組基本假定：(1)在類似的程序中，單位長度程序里的故障數(shù)Et/It近似為常數(shù)。根據(jù)美國的一些統(tǒng)計(jì)數(shù)據(jù)：0.5×10－2≤Et/It≤2×10－2，也就是說，在正常情況下，測(cè)試之前，1000條指令里大約有5～20個(gè)缺陷。(2)軟件失效率正比于軟件中潛藏的缺陷數(shù)，而MTTF和潛藏的缺陷數(shù)成反比。(3)假定發(fā)現(xiàn)的缺陷都及時(shí)得到了改正，所以，Ed(τ)=Ec(τ)。(4)剩余的缺陷數(shù)：Er(τ)=Et－Ec(τ)。(5)單位長度程序中剩余的缺陷數(shù)為：Et/It－Ec(τ)/It。估算平均無故障運(yùn)行時(shí)間：經(jīng)驗(yàn)表明，軟件的平均無故障時(shí)間和單位長度程序中剩余的故障數(shù)成反比，即其中，K為常數(shù)，它的取值應(yīng)當(dāng)根據(jù)歷史數(shù)據(jù)選取。美國的一些統(tǒng)計(jì)數(shù)據(jù)表明，K的典型值為200。按照上式，可以估算出MTTF值，在用戶提出了MTTF指標(biāo)的情況下，也可以據(jù)此判斷發(fā)現(xiàn)多少個(gè)錯(cuò)誤后才可以結(jié)束測(cè)試工作。(19.4)1.植入故障法在測(cè)試之前，由專人在程序中隨機(jī)地植入一些錯(cuò)誤，測(cè)試之后，根據(jù)測(cè)試小組發(fā)現(xiàn)的故障中原有的和植入的兩種故障的比例，來估計(jì)程序中原有的總故障數(shù)Et。假設(shè)人為地植入了Ns個(gè)故障，經(jīng)過一段時(shí)間的測(cè)試后，發(fā)現(xiàn)了ns個(gè)植入的故障，此外還發(fā)現(xiàn)了n個(gè)原有的故障。假定測(cè)試人員發(fā)現(xiàn)原有故障和植入故障的能力相同，那么能夠在概率的意義上，估計(jì)出程序中原有的故障總數(shù)大約為(19.5)

2.分別測(cè)試法植入故障法的基本假定是所用的測(cè)試方案發(fā)現(xiàn)植入錯(cuò)誤和原有錯(cuò)誤的概率相同。但是這種假設(shè)并不總是成立，因此有時(shí)計(jì)算結(jié)果有較大的偏差。設(shè)想由兩個(gè)測(cè)試人員同時(shí)測(cè)試一個(gè)軟件程序的兩個(gè)副本。用T表示測(cè)試時(shí)間。在T=0時(shí)，故障總數(shù)為B0；T=T1時(shí)，測(cè)試員甲發(fā)現(xiàn)的故障數(shù)為B1；T=T1時(shí)，測(cè)試員乙發(fā)現(xiàn)的故障數(shù)為B2；T=T1時(shí)，測(cè)試員甲、乙發(fā)現(xiàn)的相同故障數(shù)為Bc；則在統(tǒng)計(jì)的角度上，測(cè)試之前的故障總數(shù)：為進(jìn)一步求精，可以每隔一段時(shí)間進(jìn)行一次并行測(cè)試，如果幾次估算的結(jié)果相差不多，則可取其均值作為Et的結(jié)果估算值。(19.6)19.6SQA計(jì)劃為了有序地開展軟件質(zhì)量保證活動(dòng)，必須制定專項(xiàng)的SQA計(jì)劃來指導(dǎo)全部的SQA活動(dòng)，并作為項(xiàng)目開發(fā)計(jì)劃的一個(gè)組成部分。SQA計(jì)劃應(yīng)當(dāng)由SQA小組和項(xiàng)目組共同制定，并進(jìn)行評(píng)審。IEEE組織推薦了一份SQA計(jì)劃大綱(如表19.4所示)，開發(fā)組織可以結(jié)合項(xiàng)目的實(shí)際情況對(duì)大綱進(jìn)行裁減、充實(shí)后，制定項(xiàng)目的SQA計(jì)劃。計(jì)劃的開始部分描述制訂SQA計(jì)劃的目的和涉及到的文檔范圍，并指出SQA活動(dòng)所覆蓋的軟件過程活動(dòng)。所有在SQA計(jì)劃中將要提到的文檔都要列出來，所有可應(yīng)用的標(biāo)準(zhǔn)都專門注明。計(jì)劃中的“管理”部分描述SQA組在組織結(jié)構(gòu)中的位置、SQA任務(wù)和活動(dòng)及它們?cè)谡麄€(gè)軟件過程中的位置，以及與產(chǎn)品質(zhì)量有關(guān)的角色和責(zé)任。文檔一節(jié)描述的是軟件過程各個(gè)部分所產(chǎn)生的各種工作產(chǎn)品。包括：項(xiàng)目文檔(例如項(xiàng)目計(jì)劃)、工程過程模型、技術(shù)文檔、用戶文檔等等。表19.4SQA計(jì)劃大綱1．計(jì)劃目的2．參考文獻(xiàn)3．管理3.1組織3.2任務(wù)3.3責(zé)任4．文檔4.1目的4.2所需的軟件工程文檔4.3其他文檔5．標(biāo)準(zhǔn)、實(shí)踐和約定5.1目的5.2約定6．復(fù)審和審核6.1目的6.2復(fù)審需求a.軟件需求復(fù)審b.設(shè)計(jì)復(fù)審c.軟件驗(yàn)證和確認(rèn)復(fù)審d.功能審核e.物理審核f.過程內(nèi)部審核g.管理復(fù)審7．測(cè)試8．問題報(bào)告和改正行動(dòng)9．SQA工具、技術(shù)和方法學(xué)10．代碼控制11．媒體控制