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

1、第19章 軟件質(zhì)量保證 第19章 軟件質(zhì)量保證 19.1 軟件質(zhì)量與軟件質(zhì)量與SQA 19.2 軟件復審軟件復審 19.3 正式的技術復審正式的技術復審 19.4 基于統(tǒng)計的質(zhì)量保證基于統(tǒng)計的質(zhì)量保證19.5 軟件可靠性軟件可靠性 19.6 SQA計劃計劃 19.7 小結小結 第19章 軟件質(zhì)量保證 16.1 軟件質(zhì)量與軟件質(zhì)量與SQA16.1.1 軟件質(zhì)量軟件質(zhì)量 在ANSI / IEEE的729-1983號標準中定義軟件質(zhì)量為：“與軟件產(chǎn)品滿足規(guī)定和隱含需求的能力有關的全體特征(或特性)”。 為滿足軟件的各項規(guī)定的或隱含的功能、性能需求，符合文檔化開發(fā)標準，就需要相應地設計出一些質(zhì)量特性及

2、其組合質(zhì)量目標，作為在軟件開發(fā)與維護中的重要考慮因素。如果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，則這個軟件產(chǎn)品的質(zhì)量就是高的。這些被定義出來的特性及其組合就稱之為軟件的“質(zhì)量目標”。第19章 軟件質(zhì)量保證 從上述軟件質(zhì)量的定義中，反映出了以下三個方面的問題。 (1) 軟件需求是度量軟件質(zhì)量的基礎。不符合需求的軟件就不具備質(zhì)量。 (2) 軟件人員必須遵循軟件過程規(guī)范，用工程化的方法來開發(fā)軟件。如果不遵守這些規(guī)程，軟件質(zhì)量就沒有保證。 (3) 往往會有一些隱含的需求沒有明確地提出來。如果軟件只是滿足那些規(guī)定的需求而不可能滿足那些可能存在的隱含需求，軟件質(zhì)量也不能保證。第19章 軟件質(zhì)量保證 軟

3、件質(zhì)量是各種特性的復雜組合，它隨著應用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。在計算機發(fā)展的早期(20世紀50和60年代)，軟件質(zhì)量保證工作曾經(jīng)只由程序員來承擔。20世紀70年代，美國軍方在軟件開發(fā)合同中首先提出了軟件質(zhì)量保證的標準，提出了軟件質(zhì)量保證活動的定義是為了保證軟件質(zhì)量而必須的“有計劃的和系統(tǒng)化的行動模式”這一觀點。這一定義的含義是要求在一個組織中應當由多個機構共同協(xié)作，承擔保證軟件質(zhì)量的責任。包括軟件工程師、項目管理者、客戶、銷售人員和SQA小組的人員。 第19章 軟件質(zhì)量保證 SQA小組是軟件開發(fā)組織中獨立于任何項目組的專職品質(zhì)保證組織。他們以客戶的觀點來看待軟件，通過自

4、己的工作來回答軟件是否滿足各項質(zhì)量指標、軟件開發(fā)是否按照預先設定的標準進行、作為SQA活動一部分的技術規(guī)程是否恰當?shù)匕l(fā)揮了作用等問題。換句話說，SQA針對工作過程與標準的符合性、工作產(chǎn)品與標準的符合性進行審核與審查。第19章 軟件質(zhì)量保證 19.1.2 SQA活動活動 軟件質(zhì)量保證活動由各種任務構成。這些任務分別和從事技術工作的軟件工程師和負責對質(zhì)量保證活動進行計劃、監(jiān)督、記錄、分析、報告工作的專職SQA小組成員相關。 軟件工程師通過采用可靠的技術方法和措施，進行正式的技術復審，執(zhí)行計劃周密的軟件測試來考慮軟件質(zhì)量問題并保證軟件質(zhì)量；SQA小組的職責是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。SE

5、I推薦了一組有關軟件質(zhì)量保證活動中的計劃、監(jiān)督、記錄分析及報告的SQA活動。這些活動由一個獨立的SQA小組執(zhí)行。按照SEI的建議，具體的SQA活動應當包括：第19章 軟件質(zhì)量保證 (1) 為項目準備SQA計劃：該計劃在制定項目開發(fā)計劃時制訂，由所有對質(zhì)量感興趣的相關部門復審。該計劃將控制由軟件工程小組和SQA小組執(zhí)行的軟件質(zhì)量保證活動。在SQA計劃中，應當包含：需要進行的評價；需要進行的審查和復審；項目可以采用的標準；錯誤報告和跟蹤過程；由SQA小組產(chǎn)生的文檔目錄；為軟件項目組提供的反饋數(shù)據(jù)種類。 (2) 參與開發(fā)該項目的軟件過程：軟件工程小組為將要進行的工作選擇一個工程過程。SQA小組將復審

6、過程說明，以保證該過程與組織政策、內(nèi)部軟件標準、外部標準以及軟件開發(fā)計劃的其他部分相符合。 第19章 軟件質(zhì)量保證 (3) 復審各項軟件工程活動：對工程活動是否符合定義好的軟件工程過程進行核實。SQA小組識別、記錄和跟蹤實際工作與已定義過程之間的偏差，提出報告要求改正的地方并對是否已經(jīng)改正進行跟蹤與核實。 (4) 審查指定的軟件工作產(chǎn)品，對其是否符合定義好的軟件工程過程中的相應部分進行核實。SQA小組要對選出的產(chǎn)品進行復審，識別、記錄和跟蹤產(chǎn)品與過程規(guī)定的偏差，并對是否已經(jīng)改正進行跟蹤核實。定期地將工作結果向項目管理者報告。 第19章 軟件質(zhì)量保證 (5) 確保軟件工作及工作產(chǎn)品中的偏差已記錄

7、在案，并按照預定規(guī)程進行處理。偏差可能出現(xiàn)在項目計劃、過程描述、采用的標準或技術工作產(chǎn)品中。 (6) 記錄所有的不符合部分，并報告給高級管理者，對不符合部分進行跟蹤，直到問題得到解決。 此外，SQA小組還要協(xié)調(diào)變更的控制和管理，并協(xié)助收集項目度量信息。第19章 軟件質(zhì)量保證 16.2 軟軟 件件 復復 審審19.2.1 軟件復審軟件復審 軟件復審是軟件工程過程中濾除缺陷的“過濾器”。在軟件項目開發(fā)過程中的多個不同的點上，軟件復審活動能夠起到及早發(fā)現(xiàn)錯誤進而引發(fā)排錯活動的作用。軟件復審的目的是盡可能多地發(fā)現(xiàn)被復審對象中的缺陷，起到“凈化”工作產(chǎn)品的作用。由于我們發(fā)現(xiàn)別人生產(chǎn)的工作產(chǎn)品中的缺陷比發(fā)

8、現(xiàn)自己的缺陷要容易，所以復審應當在不同的工程師之間進行。任何一次復審都是借助人的差異性來達到目標的活動，它的目標包括：第19章 軟件質(zhì)量保證 (1) 指出一個人或一個小組生產(chǎn)的產(chǎn)品所需進行的改進。 (2) 確定被審核產(chǎn)品中不需要或者不希望改進的部分。 (3) 得到與未復審時相比更加一致，至少更可預測的技術工作的質(zhì)量，從而使得技術工作更可管理。 復審的方式很多，包括非正式的復審、正式的同行評審、管理復審等等。 第19章 軟件質(zhì)量保證 19.2.2 軟件缺陷對成本的影響軟件缺陷對成本的影響 在軟件工程活動中，“缺陷”是指在軟件交付給最終用戶后發(fā)現(xiàn)的質(zhì)量問題；而“錯誤”描述在軟件交付前由軟件工程師發(fā)

9、現(xiàn)的質(zhì)量問題。很明顯，缺陷帶來的危害遠大于“錯誤”帶來的影響。因此，正式技術復審的主要目標就是在復審過程中發(fā)現(xiàn)錯誤，以便潛在的缺陷在交付之前變成“錯誤”并得到糾正。正式技術復審的明顯優(yōu)點就是能夠較早發(fā)現(xiàn)錯誤，防止錯誤傳播到軟件過程的后繼階段?！氨M早”發(fā)現(xiàn)錯誤是我們的追求，因為同樣的錯誤對成本和工期產(chǎn)生的影響與發(fā)現(xiàn)錯誤、改正錯誤的時間是密切相關的。第19章 軟件質(zhì)量保證 大量的研究表明，設計活動引入的錯誤占軟件過程中出現(xiàn)的所有錯誤和最終缺陷數(shù)量的50%70%。而近期的研究表明，正式的技術復審在發(fā)現(xiàn)設計錯誤方面有最高達到75%的有效性。由于能夠通過復審檢測和排除大量的設計錯誤，復審過程將可望極大地

10、降低后繼開發(fā)和維護階段的工作成本。根據(jù)從多個大型項目中采集的數(shù)據(jù)表明，假如在設計階段發(fā)現(xiàn)的一個錯誤的改正成本是1個貨幣單位，那么在測試之前發(fā)現(xiàn)的一個錯誤的改正成本就是6.5個貨幣單位，在測試時發(fā)現(xiàn)一個錯誤的改正成本變成15個貨幣單位，而在發(fā)布之后，改進一處缺陷的成本達到60100個貨幣單位。因此，盡可能早地發(fā)現(xiàn)錯誤，是降低軟件錯誤/缺陷對工程成本影響的有效途徑。第19章 軟件質(zhì)量保證 19.2.3 缺陷的放大和消除缺陷的放大和消除 可以用“缺陷放大模型”來說明及時的復審在軟件工程中的作用(如圖19.1所示)。圖中，方塊表示一個開發(fā)步驟，可能因疏忽而產(chǎn)生錯誤。復審過程可能沒有完全發(fā)現(xiàn)來自此步驟之

11、前的和新發(fā)生的所有錯誤。從而可能在本階段“繼承”了一些錯誤，并將一部分錯誤引入下一階段。其中，一部分來自前一階段的錯誤可能會誤導本階段的工作，導致在錯誤的基礎上產(chǎn)生更多的錯誤，形成錯誤的“放大”效應。第19章 軟件質(zhì)量保證 圖19.1 缺陷的放大模型第19章 軟件質(zhì)量保證 圖19.2是一個沒有進行技術復審的軟件開發(fā)過程中缺陷放大的例子。樂觀地設想，在每一個測試步驟都能夠發(fā)現(xiàn)并改正50%的輸入錯誤，而又不引入新的錯誤。在圖中明顯地看到，最初在概要設計階段產(chǎn)生的10個錯誤，到集成測試之前已經(jīng)放大成為94個。12個隱藏的缺陷將隨著軟件的發(fā)布擴散到用戶處。表16.1是無復審情況下缺陷放大數(shù)據(jù)及因此增加

12、的成本數(shù)據(jù)。第19章 軟件質(zhì)量保證 圖19.2 缺陷的放大無復審第19章 軟件質(zhì)量保證 表表19.1 無復審情況下軟件缺陷對成本的影響無復審情況下軟件缺陷對成本的影響錯誤發(fā)現(xiàn)時機缺陷數(shù)量成本單位成本總計測試之前226.5143測試期間82151230發(fā)布之后1267804缺陷總成本 2177第19章 軟件質(zhì)量保證 從圖19.3中可以看到，只要在每個工程階段都進行復審工作，就能夠有效地遏制缺陷放大的勢頭，從而減少缺陷對成本的影響。在概要設計階段同樣是10個錯誤，到集成測試時僅擴展為24個，最終輸出到用戶處的缺陷只有三個。表19.2是有復審情況下缺陷 數(shù)據(jù)及因此增加的成本數(shù)據(jù)。 從上例中能夠清晰地

13、看出，實行復審能夠及早地發(fā)現(xiàn)大部分錯誤，極大地減少交付產(chǎn)品中的缺陷數(shù)，降低因修正缺陷帶來的成本。當然，為了進行復審，開發(fā)人員也必須投入工作量，也就是說，組織必須為復審支付成本。但復審增加的成本和因進行了復審而降低的糾正錯誤和缺陷的成本相比，是相當?shù)偷?。因此，軟件開發(fā)組織應當在各個工作階段上組織進行有效的復審，以便消除缺陷，減少缺陷成本，保證軟件質(zhì)量。第19章 軟件質(zhì)量保證 圖19.3 缺陷的放大有復審第19章 軟件質(zhì)量保證 表表19.2 有復審情況下軟件缺陷對成本的影響有復審情況下軟件缺陷對成本的影響錯誤發(fā)現(xiàn)時機缺陷數(shù)量成本單位成本總計設計期間221.533測試之前366.5234測試期間15

14、15315發(fā)布之后367201缺陷總成本 783第19章 軟件質(zhì)量保證 19.3 正式的技術復審正式的技術復審 正式技術復審(FTR)是一種由技術工程師進行的軟件質(zhì)量保證活動。FTR的目標是： (1) 在軟件的任何一種表示形式中發(fā)現(xiàn)功能、邏輯或實現(xiàn)上的錯誤。 (2) 證實經(jīng)過復審的軟件的確滿足需求。 (3) 保證軟件的表示符合預定義的標準。 (4) 得到一種以一致的方式開發(fā)的軟件。第19章 軟件質(zhì)量保證 (5) 使項目更加容易管理。因為FTR的進行使大量人員對軟件系統(tǒng)中原本并不熟悉的部分更加了解，因此，F(xiàn)TR還起到了提高項目連續(xù)性和培訓后備人員的作用。 FTR實際上是一類復審方式，包括“走查”

15、(Walkthrough)、“審查”(Inspection)、“輪查”(Round Robin Review)以及其他軟件小組的技術評估。每次的FTR都以會議的形式進行，只有經(jīng)過適當?shù)赜媱?、控制和相關人員的積極參與，F(xiàn)TR才能獲得成功。第19章 軟件質(zhì)量保證 19.3.1 復審會議的組織復審會議的組織 從保證會議效果出發(fā)，不論進行什么形式的FTR活動，會議的規(guī)模都不宜過大，控制在35人較好；每個參會人員都要提前進行準備，但是復審準備工作占用的工作時間應當少于兩小時；會議的時間不宜長，控制在兩個小時之內(nèi)。 考慮到這樣的約束，每次復審的對象顯然應當只是整個軟件中的某個較小的特定部分。不要試圖一次復

16、查整個設計，而要對每個模塊或者一小組模塊進行復審走查。經(jīng)驗證明，當一次FTR關注的范圍較小時，發(fā)現(xiàn)錯誤的可能性更大一些。第19章 軟件質(zhì)量保證 FTR的焦點是某個工作產(chǎn)品，比如一部分需求規(guī)約，一個模塊的詳細設計，一個模塊的源代碼清單等等。負責生產(chǎn)這個產(chǎn)品的人通知“復審責任人”產(chǎn)品已經(jīng)完成，需要復審。復審責任人對工作產(chǎn)品的完成情況進行評估，當確認已經(jīng)具備復審條件后，準備產(chǎn)品副本，發(fā)放給預定要參加復審的復審者。復審者花12小時進行準備。通常在第二天召開復審會議。復審會議由復審責任人主持，產(chǎn)品生產(chǎn)者和所有的復審者參加，并安排專門的記錄員。產(chǎn)品生產(chǎn)者在會議上要“遍歷”工作產(chǎn)品并進行講解，復審者則根據(jù)各

17、自的準備提出問題。當發(fā)現(xiàn)錯誤和問題時，記錄員將逐一進行記錄。第19章 軟件質(zhì)量保證 在復審結束時，必須做出復審結論。結論只能是下列三種之一： (1) 工作產(chǎn)品可以不經(jīng)修改地被接收。 (2) 由于存在嚴重錯誤，產(chǎn)品被否決(錯誤改正后必須重新復審)。 (3) 暫時接收工作產(chǎn)品(發(fā)現(xiàn)了輕微錯誤需要改正，但改正后無需再次評審)。 參與復審的所有人員，都必須在結論上簽字以表示他們參加了本次FTR，并同意復審小組的結論。第19章 軟件質(zhì)量保證 19.3.2 復審報告和記錄保存復審報告和記錄保存 在FTR期間，一名復審者(記錄員)主動記錄所有被提出來的問題。在會議結束時對這些問題進行小結，并形成一份“復審問

18、題列表”。 此外還要形成一份簡單的“復審總結報告”。復審總結報告中將闡明如下問題： 復審對象是什么； 有哪些人參與復審； 發(fā)現(xiàn)了什么，結論是什么。第19章 軟件質(zhì)量保證 復審報告是項目歷史記錄的一部分，可以分發(fā)給項目負責人和其他感興趣的復審參與方。復審問題列表有兩個作用，首先是標識產(chǎn)品中的問題區(qū)域，其次將被用作指導生產(chǎn)者對產(chǎn)品進行改進的“行動條目”。 在復審總結報告中，復審問題列表應當作為附件。 SQA人員必須參與復審。他們一方面觀察復審過程的合理性，另一方面將會在今后對問題列表中各個問題的改正情況進行跟蹤、檢查并通報缺陷修改情況，直到復審通過或問題徹底解決。第19章 軟件質(zhì)量保證 19.3.

19、3 復審指南復審指南 不受控制的錯誤的復審，比沒有復審更加糟糕。所以在進行正式的復審之前必須制定復審指南并分發(fā)給所有的復審參加者，得到大家的認可后，才能依照指南進行復審。正式技術復審指南的最小集合如下： (1) 復審對象是產(chǎn)品，而不是產(chǎn)品生產(chǎn)者。復審會議的氣氛應當是輕松的和建設性的，不要試圖貶低或者羞辱別人。通常，有管理職權的成員不宜作為復審者參加會議。 (2) 制訂并嚴格遵守議程。FTR會議必須保證按照計劃進行，不要離題。第19章 軟件質(zhì)量保證 (3) 鼓勵復審者提出問題，但限制爭論和辯駁。有爭議的問題記錄在案，事后解決。 (4) 復審是以“發(fā)現(xiàn)問題”為宗旨的。問題的解決通常由生產(chǎn)者自己或者

20、在別人的幫助下解決。所以不要試圖在FTR會議上解決所有問題。 (5) 必須設置專門的記錄員，做好會議記錄。 (6) 為保證FTR有實效，堅持要求與會者事先做好準備，提交書面的評審意見，并要限制與會人數(shù)，將人數(shù)保持在最小的必須值上。第19章 軟件質(zhì)量保證 (7) 組織應當為每類要復審的產(chǎn)品(如各種計劃、需求分析、設計、編碼、測試用例)建立檢查表，幫助復審主持者組織FTR會議，并幫助每個復審者都能夠把注意力放在對具體產(chǎn)品來說最為關鍵的問題上。 (8) 為FTR分配足夠的資源和時間，并且要為復審結果所必然導致的產(chǎn)品修改活動分配時間。 (9) 所有參與復審的人，都應當具備進行FTR的技能，接受過相關的

21、培訓。 (10) 復審以前所作的復審，總結復審工作經(jīng)驗，不斷提高復審水平。第19章 軟件質(zhì)量保證 19.4 基于統(tǒng)計的質(zhì)量保證基于統(tǒng)計的質(zhì)量保證 有經(jīng)驗的業(yè)界人士都同意下面的觀點：大多數(shù)真正麻煩的缺陷都可以追溯到數(shù)量相對有限的根本原因上。對一段較長時間內(nèi)發(fā)現(xiàn)的軟件缺陷進行收集、統(tǒng)計，并利用統(tǒng)計規(guī)律對大量的缺陷數(shù)據(jù)進行深入的分析，有助于我們逐漸發(fā)現(xiàn)導致大部分缺陷的根本原因，從而能夠將它們分離出來，集中力量予以解決。這樣，就可以在SQA活動中做到“將時間集中用在真正重要的地方”，有針對性地進行質(zhì)量保證活動。這種方法稱之為“基于統(tǒng)計的質(zhì)量保證”。第19章 軟件質(zhì)量保證 基于統(tǒng)計的SQA包括以下的步驟

22、：(1) 收集軟件缺陷信息并進行分類。(2) 嘗試對每個缺陷的成因進行追溯。(3) 通過追溯，將少數(shù)最重要的缺陷成因分離出來。(4)針對分離出的重要的缺陷成因，進行有針對性的改進活動。第19章 軟件質(zhì)量保證 假如一個軟件開發(fā)組織在一年內(nèi)利用復審、測試、用戶反饋等途徑搜集到了有關自身產(chǎn)品的錯誤 / 缺陷信息，盡管發(fā)現(xiàn)的錯誤 / 缺陷數(shù)以百計，但是經(jīng)過歸類，所有的錯誤/缺陷的原因都可以歸為下列原因中的一個或幾個：IES：說明不完整或說明錯誤；MCC：與客戶通信中產(chǎn)生誤解；IDS：故意與說明偏離；VPS：違犯編程標準；EDR：數(shù)據(jù)表示錯誤；IMI：模塊接口不一致；第19章 軟件質(zhì)量保證 EDL：設計

23、邏輯有錯；IET：不完整的或錯誤的測試；IID：不準確或不完整的文檔；PLT：將設計翻譯成預定語言時的錯誤；HCI：不清晰或不一致的人機界面；MIS：雜項。第19章 軟件質(zhì)量保證 設計一張表格，將各類錯誤/缺陷的統(tǒng)計數(shù)據(jù)和它們各自在所有錯誤/缺陷中所占的比例計算出來，以此數(shù)值為鍵值進行降序排序，造成所有錯誤/缺陷的重要原因就能夠十分清晰地凸現(xiàn)出來。表16.3中顯示IES、MCC和EDR是導致發(fā)生53%的錯誤/缺陷的“少數(shù)重要原因”。同時可以看出，如果我們將注意力集中到嚴重錯誤的成因上，那么應該將IES、EDR、PLT和EDL作為“少數(shù)重要原因”。 一旦確定了“少數(shù)重要原因”， 開發(fā)組織就可以采

24、取改進行動。例如，為了改正MCC錯誤，開發(fā)者可以采用更便于理解的軟件說明技術，提高和用戶通信交流的質(zhì)量。為了改正EDR導致的錯誤，可以使用CASE工具進行數(shù)據(jù)建模，并進行更加嚴格的數(shù)據(jù)設計復審。第19章 軟件質(zhì)量保證 當導致錯誤和缺陷的少數(shù)重要原因被識別、糾正后，一些原來不那么重要的原因會成為統(tǒng)計數(shù)據(jù)表中新的“少數(shù)重要原因”。 這樣，SQA活動能夠始終針對當前導致錯誤和缺陷的主要原因展開工作，取得事半功倍的效果。這也就是基于統(tǒng)計的質(zhì)量保證活動價值之所在。第19章 軟件質(zhì)量保證 表表19.3 統(tǒng)計統(tǒng)計SQA的數(shù)據(jù)收集與分類的數(shù)據(jù)收集與分類錯誤錯誤類別類別錯誤總計錯誤總計嚴重錯誤嚴重錯誤一般錯誤一

25、般錯誤輕微錯誤輕微錯誤數(shù)量數(shù)量百分比百分比數(shù)量數(shù)量百分比百分比數(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)計值統(tǒng)計值94210

26、0%128100%379100%435100%第19章 軟件質(zhì)量保證 19.5 軟軟 件件 可可 靠靠 性性19.5.1 可靠性和可用性可靠性和可用性 軟件可靠性的含義是：“程序在給定的時間間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功地運行的概率”。在這個定義中包含的隨機變量是“時間間隔”。顯然隨著運行時間的增加，運行時遇到程序故障的概率也將增加，即可靠性隨著時間間隔的加大而減小。 除可靠性之外，用戶也非常關心軟件系統(tǒng)可以使用的程度。一般來說，對于任何一個可以修復的系統(tǒng)，都應當同時使用可靠性和可用性來衡量它的優(yōu)劣。軟件可用性的一個定義是：“程序在給定的時間點，按照規(guī)格說明書的規(guī)定成功地運行的概率”。第19

27、章 軟件質(zhì)量保證 可靠性和可用性之間的主要差別在于：可靠性意味著在0t這段時間間隔內(nèi)系統(tǒng)沒有失效；而可用性只是意味著在時刻t系統(tǒng)是正常運行的。因此，如果在時刻t系統(tǒng)是可用的，則包括下述種種可能：在0t這段時間里，系統(tǒng)一直沒有失效；在這段時間里失效了一次，但是又修復了；在這段時間里失效了兩次、又修復了兩次. 如果在一段時間里，軟件系統(tǒng)故障停機時間分別為td1，td2，td3 .正常運行時間分別為tu1，tu2，tu3 .則系統(tǒng)的穩(wěn)態(tài)可用性為upssupdownTA =(T +T)(19.1)第19章 軟件質(zhì)量保證 其中，Tup = tui ，Tdown = tdi。 如果引進系統(tǒng)平均無故障時間M

28、TTF和系統(tǒng)平均維修時間MTTR的概念，那么，軟件系統(tǒng)的穩(wěn)態(tài)可用性可以表示為ssMTTFA =MTTF+MTTR 平均維修時間MTTR是修復一個故障平均需要的時間，它取決于維護人員的技術水平和對系統(tǒng)的熟悉程度，也和系統(tǒng)的可維護性有重要關系。平均無故障時間MTTF是系統(tǒng)按照規(guī)格說明書的規(guī)定成功運行的平均時間，它主要取決于系統(tǒng)中潛伏的缺陷數(shù)目，因此和測試的關系十分密切。(19.2)第19章 軟件質(zhì)量保證 為了直觀地度量軟件的可靠性，還可以采用“平均失效間隔時間”MTBF。MTBF = MTTF + MTTR(19.3)第19章 軟件質(zhì)量保證 19.5.2 平均無故障運行時間的估算平均無故障運行時間

29、的估算 軟件的平均無故障運行時間MTTF是一個重要的質(zhì)量指標，用戶往往把MTTF作為對軟件的一種性能需求提出來。為滿足用戶的需求，開發(fā)組織就應當在交付產(chǎn)品時估算出產(chǎn)品的MTTF值。第19章 軟件質(zhì)量保證 為了估算MTTF，首先引入一組符號：Et ：測試之前程序中的缺陷總數(shù)；It ：用機器指令總數(shù)衡量的程序長度； ：測試(包括調(diào)試)時間；Ed()：在0時間內(nèi)發(fā)現(xiàn)的錯誤總數(shù)；Ec()：在0時間內(nèi)改正的錯誤總數(shù)；Er：在0時間后剩余的缺陷數(shù)。第19章 軟件質(zhì)量保證 建立一組基本假定： (1) 在類似的程序中，單位長度程序里的故障數(shù)Et / It 近似為常數(shù)。根據(jù)美國的一些統(tǒng)計數(shù)據(jù)：0.5102 Et

30、 / It 2102，也就是說，在正常情況下，測試之前，1000條指令里大約有520個缺陷。 (2) 軟件失效率正比于軟件中潛藏的缺陷數(shù)，而MTTF和潛藏的缺陷數(shù)成反比。 (3) 假定發(fā)現(xiàn)的缺陷都及時得到了改正，所以，Ed() = Ec()。 (4) 剩余的缺陷數(shù)：Er() = EtEc()。 (5) 單位長度程序中剩余的缺陷數(shù)為：Et / ItEc() / It。第19章 軟件質(zhì)量保證 估算平均無故障運行時間：經(jīng)驗表明，軟件的平均無故障時間和單位長度程序中剩余的故障數(shù)成反比，即ttct1MTTF=K(E /I -E ()/I ) 其中，K為常數(shù)，它的取值應當根據(jù)歷史數(shù)據(jù)選取。美國的一些統(tǒng)計數(shù)

31、據(jù)表明，K的典型值為200。按照上式，可以估算出MTTF值，在用戶提出了MTTF指標的情況下，也可以據(jù)此判斷發(fā)現(xiàn)多少個錯誤后才可以結束測試工作。(19.4)第19章 軟件質(zhì)量保證 1. 植入故障法植入故障法 在測試之前，由專人在程序中隨機地植入一些錯誤，測試之后，根據(jù)測試小組發(fā)現(xiàn)的故障中原有的和植入的兩種故障的比例，來估計程序中原有的總故障數(shù)Et。假設人為地植入了Ns個故障，經(jīng)過一段時間的測試后，發(fā)現(xiàn)了ns個植入的故障，此外還發(fā)現(xiàn)了n個原有的故障。假定測試人員發(fā)現(xiàn)原有故障和植入故障的能力相同，那么能夠在概率的意義上，估計出程序中原有的故障總數(shù)大約為 snN=Nn(19.5)第19章 軟件質(zhì)量保

32、證 2. 分別測試法分別測試法 植入故障法的基本假定是所用的測試方案發(fā)現(xiàn)植入錯誤和原有錯誤的概率相同。但是這種假設并不總是成立，因此有時計算結果有較大的偏差。設想由兩個測試人員同時測試一個軟件程序的兩個副本。用T表示測試時間。 在 T = 0時，故障總數(shù)為B0； T = T1時，測試員甲發(fā)現(xiàn)的故障數(shù)為B1； T=T1時，測試員乙發(fā)現(xiàn)的故障數(shù)為B2； T=T1時，測試員甲、乙發(fā)現(xiàn)的相同故障數(shù)為Bc；第19章 軟件質(zhì)量保證 則在統(tǒng)計的角度上，測試之前的故障總數(shù)：B2 B1B0=Bc 為進一步求精，可以每隔一段時間進行一次并行測試，如果幾次估算的結果相差不多，則可取其均值作為Et的結果估算值。(19

33、.6)第19章 軟件質(zhì)量保證 19.6 SQA 計計 劃劃 為了有序地開展軟件質(zhì)量保證活動，必須制定專項的SQA計劃來指導全部的SQA活動，并作為項目開發(fā)計劃的一個組成部分。SQA計劃應當由SQA小組和項目組共同制定，并進行評審。IEEE組織推薦了一份SQA計劃大綱(如表19.4所示)，開發(fā)組織可以結合項目的實際情況對大綱進行裁減、充實后，制定項目的SQA計劃。 計劃的開始部分描述制訂SQA計劃的目的和涉及到的文檔范圍，并指出SQA活動所覆蓋的軟件過程活動。所有在SQA計劃中將要提到的文檔都要列出來，所有可應用的標準都專門注明。第19章 軟件質(zhì)量保證 計劃中的“管理”部分描述SQA組在組織結構

34、中的位置、SQA任務和活動及它們在整個軟件過程中的位置，以及與產(chǎn)品質(zhì)量有關的角色和責任。 文檔一節(jié)描述的是軟件過程各個部分所產(chǎn)生的各種工作產(chǎn)品。包括：項目文檔(例如項目計劃)、工程過程模型、技術文檔、用戶文檔等等。第19章 軟件質(zhì)量保證 表表19.4 SQA計劃大綱計劃大綱1計劃目的2參考文獻3管理3.1 組織3.2 任務3.3 責任4文檔4.1 目的4.2 所需的軟件工程文檔 4.3 其他文檔5標準、實踐和約定5.1 目的 5.2 約定6復審和審核6.1 目的 6.2 復審需求a.軟件需求復審b.設計復審c.軟件驗證和確認復審d.功能審核e.物理審核f.過程內(nèi)部審核g.管理復審7測試8問題報告和改正行動 9SQA工具、技術和方法學10代碼控制11媒體