軟件質(zhì)量保證(共11頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件質(zhì)量保證    軟件質(zhì)量保證   軟件質(zhì)量保證（SQA）是建立一套有計劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。    軟件質(zhì)量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質(zhì)量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構(gòu)方針的要求。    一、基本目標  

2、; 目標 1: 軟件質(zhì)量保證工作是有計劃進行的。   目標 2: 客觀地驗證軟件項目產(chǎn)品和工作是否遵循恰當?shù)臉藴?、步驟和需求。   目標 3: 將軟件質(zhì)量保證工作及結(jié)果通知給相關(guān)組別和個人。   目標 4: 高級管理層接觸到在項目內(nèi)部不能解決的不符合類問題。   二、QA的由來   我們知道，國外很多的大公司，QA的職責就是測試（主要是系統(tǒng)測試），比如IBM

3、、CA、PeopleSoft等。其實在最初，幾乎所有的公司都是這樣的。后來，由于缺乏有效的項目計劃和項目管理，留給系統(tǒng)測試的時間很少（注：我以前做的一個項目，項目經(jīng)理就明確告訴我系統(tǒng)測試就1天，沒得商量）。另外，需求變化太快，沒有完整的需求文檔，測試人員就只能根據(jù)自己的想象來測試。這樣一來，測試就很難保障產(chǎn)品的質(zhì)量，事先預(yù)防的QA職能就應(yīng)運而生。    事先預(yù)防其實是借鑒了TQM的思想，而且也符合軟件工程“缺陷越早發(fā)現(xiàn)越早修改越經(jīng)濟”的原則。這些思想的淵源還可以追溯到中國古代的典故中，比如曲突徙薪、扁鵲論醫(yī)術(shù)等。   三、Q

4、A的現(xiàn)在   目前，實施CMM的企業(yè)越來越多了。CMM模型就要求建立QA角色。這里的QA類似于過程警察，主要職責是，檢查開發(fā)和管理活動是否與已定的過程策略、標準和流程一致，檢查工作產(chǎn)品是否遵循模板規(guī)定的內(nèi)容和格式。在這些企業(yè)中，一般還要求QA獨立于項目組，以保障評價的客觀性。從國內(nèi)來看，多數(shù)的QA沒有技術(shù)背景，檢查出的偏差多為雞毛蒜皮，再加上自己沒有令人信服的背景，領(lǐng)導(dǎo)也不支持，當然做起來就很困難了。    缺乏信任和支持只是一個方面，QA工作本身就很具挑戰(zhàn)性。它要求QA具有軟件工程的知識、軟件開發(fā)的知識、行業(yè)背景的知識、數(shù)

5、理統(tǒng)計的知識、項目管理的知識、質(zhì)量管理的知識等等。   我們常常遇到這樣的問題，改進到一定程度就很難突破，感覺心有余而力不足了，就開始郁悶了。后來通過學(xué)習(xí)、培訓(xùn)、交流，思想和技能得到升華，又發(fā)現(xiàn)了木桶中最短的那塊，然后又開始改進，然后又遇到了玻璃天花板，然后就這樣處于郁悶的循環(huán)中。   假使我們掌握了所有的知識，能突破所有的玻璃天花板，那是不是QA就可以一帆風順了。答案是否定的。QA角色定義本身就有很大的局限性。QA充當?shù)氖沁^程警察的角色，無論是否有意義，都專橫地強制過程的執(zhí)行，容易在項目組中造成敵對的關(guān)系，受到排擠，而且這種警察的姿

6、態(tài)也破壞了團隊精神。如此一來，QA工作還需要的是人際關(guān)系技能，就如我以前寫的質(zhì)量平衡和QA應(yīng)該獨立于項目組嗎？一樣，藝術(shù)化地處理這種關(guān)系。    四、QA的未來   從某種程度上說，獨立的QA審查機制是瀑布模型的產(chǎn)物。隨著現(xiàn)代軟件開發(fā)技術(shù)的演變，螺旋模型和迭代模型的興起，QA機制正在悄然發(fā)生變化。這種變化就是從獨立專職的QA向貫穿過程的兼職QA演變。在CMMI模型中，這種兼職的QA也是被允許的。為什么會發(fā)生這種改變呢？無論是XP、RUP還是其它先進的方法論，都是先產(chǎn)生架構(gòu)，然后再增量開發(fā)，直到完成。這種模式中，需求和設(shè)計缺陷

7、在各個迭代周期被所盡早發(fā)現(xiàn)和修復(fù)，質(zhì)量也內(nèi)建于架構(gòu)和過程中，項目的成本和進度也得到保障。    到那時，是不是獨立的QA就不復(fù)存在了呢？有些成熟度較低的企業(yè)還是需要的，主要是保證過程執(zhí)行的有效性和評價的客觀性。    五、SQA的理論探索    1、過程的認識    我們都知道一個項目的主要內(nèi)容是：成本、進度、質(zhì)量；良好的項目管理就是綜合三方面的因素，平衡三方面的目標，最終依照目標完成任務(wù)。項目的這三個方面是相互制約和影響的，有時對這三

8、方面的平衡策略甚至成為一個企業(yè)級的要求，決定了企業(yè)的行為，我們知道 IBM的軟件是以質(zhì)量為最重要目標的，而微軟的“足夠好的軟件”策略更是耳熟能詳，這些質(zhì)量目標其實立足于企業(yè)的戰(zhàn)略目標。所以用于進行質(zhì)量保證的SQA工作也應(yīng)當立足于企業(yè)的戰(zhàn)略目標，從這個角度思考SQA，形成對SQA的理論認識。    軟件界已經(jīng)達成共識的：影響軟件項目進度、成本、質(zhì)量的因素主要是 “人、過程、技術(shù)”。首先要明確的是這三個因素中，人是第一位的。    現(xiàn)在許多實施 CMM的人員沉溺于CMM的理論過于強調(diào)“過程

9、”，這是很危險的傾向。這個思想傾向在國外受到了猛烈抨擊，從某種意義上各種敏捷過程方法的提出就是對強調(diào)過程的一種反思。 “XP”中的一個思想“人比過程更重要” 是值得我們思考的。我個人的意見在進行過程改進中堅持“以人為本”，強調(diào)過程和人的和諧。    根據(jù)現(xiàn)代軟件工程對眾多失敗項目的調(diào)查，發(fā)現(xiàn)管理是項目失敗的主要原因。這個事實的重要性在于說明了 “要保證項目不失敗，我們應(yīng)當更加關(guān)注管理”，注意這個事實沒有說明另外一個問題“良好的管理可以保證項目的成功”?，F(xiàn)在很多人基于一種粗糙的邏輯，從一個事實反推到的這個結(jié)論，在邏輯上是錯誤的

10、，這種錯誤形成了更加錯誤的做法，這點在SQA的理解上是體現(xiàn)較深。    如果我們考證一下歷史的沿革，應(yīng)當更加容易理解 CMM的本質(zhì)。CMM首先是作為一個“評估標準”出現(xiàn)的，主要評估的是美國國防部供應(yīng)商保證質(zhì)量的能力。CMM關(guān)注的軟件生產(chǎn)有如下特點：   （1）質(zhì)量重要   （2）規(guī)模較大   這是 CMM產(chǎn)生的原因。它引入了“全面質(zhì)量管理”的思想，尤其側(cè)重了“全面質(zhì)量管理”中的“過程方法”，并且引入了“統(tǒng)計過程控制”的方法?？梢哉f這兩個思想是CM

11、M背后的基礎(chǔ)。   上面這些內(nèi)容形成了我對軟件過程地位、價值的基本理解；在這個基礎(chǔ)上我們可以引申討論 SQA。   2、生產(chǎn)線的隱喻   如果將一個軟件生產(chǎn)類比于一個工廠的生產(chǎn)。那么生產(chǎn)線就是過程，產(chǎn)品按照生產(chǎn)線的規(guī)定過程進行生產(chǎn)。 SQA的職責就是保證過程的執(zhí)行，也就是保證生產(chǎn)線的正常執(zhí)行。    抽象出管理體系模型的如下，這個模型說明了一個過程體系至少應(yīng)當包含 “決策、執(zhí)行、反饋”三個重要方面。   &

12、#160;QA的職責就是確保過程的有效執(zhí)行，監(jiān)督項目按照過程進行項目活動；它不負責監(jiān)管產(chǎn)品的質(zhì)量，不負責向管理層提供項目的情況，不負責代表管理層進行管理，只是代表管理層來保證過程的執(zhí)行。    3、SQA和其他工作的組合    在很多企業(yè)中，將 SQA的工作和QC、SEPG、組織級的項目管理者的工作混合在一起了，有時甚至更加注重其他方面的工作而沒有做好SQA的本職工作。    根據(jù) hjhza 的意見“中國現(xiàn)在基本有三種QA（按照工作重點不同來分

13、）：一是過程改進型，一是配置管理型，一是測試型”。我個人認為是因為SQA工作和其他不同工作組合在一起形成的。    下面根據(jù)本人經(jīng)驗對它們之間的關(guān)系進行一個說明。    4、QA和QC    兩者基本職責    QC：檢驗產(chǎn)品的質(zhì)量，保證產(chǎn)品符合客戶的需求；是產(chǎn)品質(zhì)量檢查者；   QA：審計過程的質(zhì)量，保證過程被正確執(zhí)行；是過程質(zhì)量審計者；    注意區(qū)別檢查和審計的

14、不同  檢查：就是我們常說的找茬，是挑毛病的；    審計：來確認項目按照要求進行的證據(jù)；仔細看看CMM中各個KPA中SQA的檢查采用的術(shù)語大量用到了“證實”，審計的內(nèi)容主要是過程的；對照CMM看一下項目經(jīng)理和高級管理者的審查內(nèi)容，他們更加關(guān)注具體內(nèi)容。    對照上面的管理體系模型，QC進行質(zhì)量控制，向管理層反饋質(zhì)量信息；QA則確保QC按照過程進行質(zhì)量控制活動，按照過程將檢查結(jié)果向管理層匯報。這就是QA和QC工作的關(guān)系。    在這樣的分工原則下，

15、60;QA只要檢查項目按照過程進行了某項活動沒有，產(chǎn)出了某個產(chǎn)品沒有；而QC來檢查產(chǎn)品是否符合質(zhì)量要求。    如果企業(yè)原來具有 QC人員并且QA人員配備不足，可以先確定由QC兼任QA工作。但是只能是暫時的，獨立的QA人員應(yīng)當具備，因為QC工作也是要遵循過程要求的，也是要被審計過程的，這種混合情況，難以保證QC工作的過程質(zhì)量。    5、QA和SEPG    兩者基本職責    SEPG：制定過程，實施過程改進； &

16、#160;  QA： 確保過程被正確執(zhí)行    SEPG應(yīng)當提供過程上的指導(dǎo)，幫助項目組制定項目過程，幫助項目組進行策劃；從而幫助項目組有效的工作，有效的執(zhí)行過程。如果項目和QA對過程的理解發(fā)生爭持，SEPG作為最終仲裁者。為了進行有效過程改進，SEPG必須分析項目的數(shù)據(jù)。    QA本也要進行過程規(guī)范，那么所有QA中最有經(jīng)驗、最有能力的QA可以參加SEPG，但是要注意這兩者的區(qū)別。    如果企業(yè)的 SEPG人員具有較為深厚的開發(fā)背景

17、，可以兼任SQA工作，這樣利于過程的不斷改進；但是由于立法、執(zhí)法集于一身也容易造成SQA過于強勢，影響項目的獨立性。    管理過程比較成熟的企業(yè)，因為企業(yè)的文化和管理機制已經(jīng)健全， SQA職責范圍的工作較少，往往只是針對具體項目制定明確重點的SQA計劃，這樣SQA的審計工作會大大減少，從而可以同時審計較多項目。    另一方面，由于分工的細致化，管理體系的復(fù)雜化，往往需要專職的 SEPG人員，這些人員要求了解企業(yè)的所有管理過程和運作情況，在這個基礎(chǔ)上才能統(tǒng)籌全局的進行過程改進，這時了解全局的S

18、QA人員就是專職SEPG的主要人選；這些SQA人員將逐漸的轉(zhuǎn)化為SEPG人員，并且更加了解管理知識，而SQA工作漸漸成為他們的兼職工作。    這種情況在許多 CMM5企業(yè)比較多見，往往有時看不見SQA人員在項目組出現(xiàn)或者很少出現(xiàn)，這種SEPG和SQA的融合特別有利于組織的過程改進工作。SEPG確定過程改進內(nèi)容，SQA計劃重點反映這些改進內(nèi)容，從保證有效的改進，特別有利于達到CMM5的要求。從這個角度，國外的SQA人員為什么高薪就不難理解了，也決定了當前中國SQA人員比較被輕視的原因；因為管理過程還不完善，我們的SQA人員還沒有產(chǎn)生這么大的價值

19、嘛！    6、QA和組織級的監(jiān)督管理    有的企業(yè)為了更好的監(jiān)督管理項目，建立了一個角色，我取名為 “組織級的監(jiān)督管理者”，他們的職責是對所有項目進行統(tǒng)一的跟蹤、監(jiān)督、適當?shù)墓芾?，來保證管理層對所有項目的可視性、可管理性。    為了有效管理項目， “組織級的監(jiān)督管理者”必須分析項目的數(shù)據(jù)。    他們的職責對照上圖的模型，就是執(zhí)行 “反饋”職能。    QA本身

20、不進行反饋工作，最多對過程執(zhí)行情況的信息進行反饋。    SQA職責最好不要和“組織級的項目管理者”的職責混合在一起，否則容易出現(xiàn)SAQ困境：一方面SQA不能準確定位自己的工作，另一方面過程執(zhí)行者對SQA人員抱有較大戒心。    如果建立了較好的管理過程，那么就會增強項目的可視性，從而保證企業(yè)對所有項目的較好管理；而 QA來確保這個管理過程的運行。    五、SQA的工作內(nèi)容和工作方法    1、 計劃 &

21、#160;  針對具體項目制定 SQA計劃，確保項目組正確執(zhí)行過程。制定SQA計劃應(yīng)當注意如下幾點：    有重點：依據(jù)企業(yè)目標以及項目情況確定審計的重點    明確審計內(nèi)容：明確審計哪些活動，那些產(chǎn)品    明確審計方式：確定怎樣進行審計    明確審計結(jié)果報告的規(guī)則：審計的結(jié)果報告給誰    2、審計/證實    依據(jù)

22、60;SQA計劃進行SQA審計工作，按照規(guī)則發(fā)布審計結(jié)果報告。    注意審計一定要有項目組人員陪同，不能搞突然襲擊。雙方要開誠布公，坦誠相對。    審計的內(nèi)容：是否按照過程要求執(zhí)行了相應(yīng)活動，是否按照過程要求產(chǎn)生了相應(yīng)產(chǎn)品。    3、問題跟蹤    對審計中發(fā)現(xiàn)的問題，要求項目組改進，并跟進直到解決。    六、SQA的素質(zhì)    過程為中心：應(yīng)當站在

23、過程的角度來考慮問題，只要保證了過程， QA就盡到了責任。    服務(wù)精神：為項目組服務(wù)，幫助項目組確保正確執(zhí)行過程    了解過程：深刻了解企業(yè)的工程，并具有一定的過程管理理論知識    了解開發(fā)：對開發(fā)工作的基本情況了解，能夠理解項目的活動    溝通技巧：善于溝通，能夠營造良好的氣氛，避免審計活動成為一種找茬活動。   七、SQA活動   軟件質(zhì)量保證（SQA）

24、是一種應(yīng)用于整個軟件過程的活動，它包含：   1、一種質(zhì)量管理方法   2、有效的軟件工程技術(shù)（方法和工具）   3、在整個軟件過程中采用的正式技術(shù)評審   4、一種多層次的測試策略   5、對軟件文檔及其修改的控制   6、保證軟件遵從軟件開發(fā)標準   7、度量和報告機制   SQA與兩種不同的參與者相關(guān)  做技術(shù)工作的軟件工程師和負責

25、質(zhì)量保證的計劃、監(jiān)督、記錄、分析及報告工作的SQA小組 。   軟件工程師通過采用可靠的技術(shù)方法和措施，進行正式的技術(shù)評審，執(zhí)行計劃周密的軟件測試來考慮質(zhì)量問題，并完成軟件質(zhì)量保證和質(zhì)量控制活動。   SQA小組的職責是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。SQA小組完成:   （1）為項目準備SQA計劃。該計劃在制定項目規(guī)定項目計劃時確定，由所有感興趣的相關(guān)部門評審。   ·需要進行的審計和評審；   ·項目可采用

26、的標準；   ·錯誤報告和跟蹤的規(guī)程；   ·由SQA小組產(chǎn)生的文檔；   ·向軟件項目組提供的反饋數(shù)量。   （2）參與開發(fā)項目的軟件過程描述。評審過程描述以保證該過程與組織政策，內(nèi)部軟件標準，外界標準以及項目計劃的其他部分相符。   （3）評審各項軟件工程活動，對其是否符合定義好的軟件過程進行核實。記錄、跟蹤與過程的偏差。   （4）審計指定的軟件工作產(chǎn)品，對其是否符合事先定義好的需

27、求進行核實。對產(chǎn)品進行評審，識別、記錄和跟蹤出現(xiàn)的偏差；對是否已經(jīng)改正進行核實；定期將工作結(jié)果向項目管理者報告。   （5）確保軟件工作及產(chǎn)品中的偏差已記錄在案，并根據(jù)預(yù)定的規(guī)程進行處理。   （6）記錄所有不符合的部分并報告給高級領(lǐng)導(dǎo)者。   八、正式技術(shù)評審（FTR）   正式技術(shù)評審是一種由軟件工程師和其他人進行的軟件質(zhì)量保障活動。   1. 目標：   (1) 發(fā)現(xiàn)功能、邏輯或?qū)崿F(xiàn)的錯誤&

28、#160;  (2) 證實經(jīng)過評審的軟件的確滿足需求   (3) 保證軟件的表示符合預(yù)定義的標準   (4) 得到一種一致的方式開發(fā)的軟件   (5) 使項目更易管理   2、評審會議   3-5人參加，不超過2小時，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個 :   （1）工作產(chǎn)品可不可以不經(jīng)修改而被接受；  &

29、#160;（2）由于嚴重錯誤而否決工作產(chǎn)品；   （3）暫時接受工作產(chǎn)品。   3、評審總結(jié)報告、回答   評審什么？由誰評審？結(jié)論是什么？   評審總結(jié)報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問題的區(qū)域，作為行政條目檢查表以指導(dǎo)生產(chǎn)者進行改正。   4、評審指導(dǎo)原則 （1） 評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松。 （2）   不要離題，限制爭論。有異議的問題不要爭論但要記錄在案。&#

30、160;  （3） 對各個問題都發(fā)表見解。問題解決應(yīng)該放到評審會議之后進行。   （4）為每個要評審的工作產(chǎn)品建立一個檢查表。應(yīng)為分析、設(shè)計、編碼、測試文檔都建立檢查表。   （5）分配資源和時間。應(yīng)該將評審作為軟件工程任務(wù)加以調(diào)度。   （6）評審以前所做的評審   九、統(tǒng)計軟件質(zhì)量保證   1、對所有錯誤進行分類統(tǒng)計   IES 規(guī)約不完整或規(guī)格說明錯  

31、0;MCC 未理解用戶意圖   IDS 故意偏離規(guī)格說明   VPS 違背編程標準   EDR 數(shù)據(jù)表示有錯   ICI 構(gòu)件接口不一致   EDL 設(shè)計邏輯有錯   IET 測試不完全或有錯   IID 不準確或不完整的文檔   PLT 設(shè)計的程序設(shè)計語言翻譯錯

32、60;  HCI 不清晰或不一致的人機界面   MIS 雜項錯誤   按嚴重，一般和微小級別統(tǒng)計各類錯誤的次數(shù)所占百分比，以及所有錯誤的數(shù)量及百分比。例如，建立一張類似如下的表格。   然后考慮“重要少數(shù)”的錯誤指標，提出改進意見。   2、根據(jù)軟件過程中的每個步驟計算錯誤指標。   Ei = 第i發(fā)現(xiàn)的錯誤總數(shù)   Si = 嚴重錯誤數(shù)

33、   Mi = 一般錯誤數(shù)   Ti = 微小錯誤數(shù)   PS = 第i步的產(chǎn)品規(guī)模( LOC，設(shè)計陳述，文檔頁數(shù))   Ws，Wm，Wt分別是嚴重，一般，微小錯誤的加權(quán)因子, 推薦取值，Ws=10，Wm=3，Wt=1   軟件工程 在過程的每一步中，計算各階段的階段指標   PIi = Ws（Si 

34、;/ Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）   錯誤指標   Ei= （i×PIi）/ PS   =（PI1 + 2PI2 + 3PI3 +  + i*PIi）/ PS   錯誤指標與上面表格中收集的信息相結(jié)合可以得出軟件質(zhì)量整體改進指標。七、質(zhì)量保證與檢驗   

35、;確保每個開發(fā)過程的質(zhì)量，防止把軟件差錯傳播到下一個過程，因此，檢驗的目的有兩個：   1切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量保證。   2預(yù)先防止軟件差錯給用戶造成損失。   檢驗的類型有:   1供貨檢驗：對委托外單位承擔開發(fā)作業(yè)，而后買進或轉(zhuǎn)讓的構(gòu)成軟件產(chǎn)品的部件，規(guī)格說明，半成品或產(chǎn)品的檢查。   2中間檢驗 / 階段評審   目的是為了判斷是否可進入下階段進行后續(xù)開發(fā)，避免將差錯

36、傳播到后續(xù)工作中。   3驗收檢驗：   確認產(chǎn)品是否已達到可以進行產(chǎn)品檢驗的質(zhì)量要求。   4產(chǎn)品檢驗：   判定向用戶提供的軟件產(chǎn)品是否達到令人滿意的程度。   十、檢驗項目內(nèi)容   1需求分析   需求分析功能設(shè)計實施計劃   檢查：開發(fā)目的；目標值；開發(fā)量；所需資源；各階段的產(chǎn)品作業(yè)內(nèi)容及開發(fā)體制的合理性。   2設(shè)計&

37、#160;  結(jié)構(gòu)設(shè)計數(shù)據(jù)設(shè)計過程設(shè)計   檢查：產(chǎn)品的計劃量與實際量；評審量；差錯數(shù)；評審方法，出錯導(dǎo)因及處理情況，階段結(jié)束的判斷標準。   3實現(xiàn)   程序編制單元測試集成測試確認測試.檢查內(nèi)容除上述外，加測試環(huán)境及測試用例設(shè)計方法。   4驗收   說明書檢查；程序檢查。   13質(zhì)量保證實施   軟件質(zhì)量評價標準。   1質(zhì)量需求

38、準則：著眼點是是否滿足用戶的要求   2質(zhì)量設(shè)計準則：開發(fā)者在設(shè)計實現(xiàn)時是否按軟件需求保證了質(zhì)量   3質(zhì)量度量準則：為質(zhì)量度量規(guī)定了一些檢查項目:   精密度量：根據(jù)質(zhì)量度量準則進行詳細度量   全面度量   簡易度量   五個實施步驟   1Target：以用戶需求和開發(fā)任務(wù)為依據(jù)，對質(zhì)量需求準則，質(zhì)量設(shè)計準則的質(zhì)量特性設(shè)定質(zhì)量目標進行評價。   2Pl

39、an：設(shè)定適合于待開發(fā)軟件的評測檢查項目，一般設(shè)定2030個。   3DO：在開發(fā)標準和質(zhì)量評價準則的指導(dǎo)下，制作高質(zhì)量的規(guī)格說明書和程序。   4Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價，算出得分，以質(zhì)量圖的形成表示出來，比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標看其是否合格。   5Action：對評價發(fā)現(xiàn)的問題進行改進活動，重復(fù)Plan到Action的過程直到開發(fā)項目完成。   14 軟件可靠性   可靠性統(tǒng)計定義：   在給定的環(huán)境和給定的時間間隔內(nèi)，按設(shè)計要求成功運行程序的概率。   二、軟件可靠性的主要指標   MTBF  平均故障間隔時間   MTTF &#