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

1、軟件質(zhì)量保證軟件質(zhì)量保證軟件質(zhì)量保證 （ SQA ） 是建立一套有計劃， 有系統(tǒng)的方法， 來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質(zhì)量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。 軟件質(zhì)量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構(gòu)方針的要求。一、基本目標目標1: 軟件質(zhì)量保證工作是有計劃進行的。目標2: 客觀地驗證軟件項目產(chǎn)品和工作是否遵循恰當?shù)臉藴?、步驟和需求。目標 3: 將軟件質(zhì)量保證工作及結(jié)果通知給相關(guān)組別和個人。 目標 4: 高級管理層接觸到在項目內(nèi)部不能

2、解決的不符合類問題。2、 QA 的由來我們知道， 國外很多的大公司， QA 的職責就是測試 （主要是系統(tǒng)測試） ， 比如 IBM 、 CA 、PeopleSoft 等。其實在最初，幾乎所有的公司都是這樣的。后來，由于缺乏有效的項目計劃和項目管理， 留給系統(tǒng)測試的時間很少 （注：我以前做的一個項目， 項目經(jīng)理就明確告訴我系統(tǒng)測試就1 天，沒得商量） 。另外，需求變化太快，沒有完整的需求文檔，測試人員就只能根據(jù)自己的想象來測試。 這樣一來， 測試就很難保障產(chǎn)品的質(zhì)量， 事先預防的 QA 職能就應(yīng)運而生。事先預防其實是借鑒了 TQM 的思想，而且也符合軟件工程“缺陷越早發(fā)現(xiàn)越早修改越經(jīng)濟”的原則。這

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

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

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

6、項目的成本和進度也得到保障。到那時，是不是獨立的 QA 就不復存在了呢？有些成熟度較低的企業(yè)還是需要的，主要是保證過程執(zhí)行的有效性和評價的客觀性。5、 SQA 的理論探索1 、過程的認識我們都知道一個項目的主要內(nèi)容是：成本、進度、質(zhì)量；良好的項目管理就是綜合三方面的因素， 平衡三方面的目標， 最終依照目標完成任務(wù)。 項目的這三個方面是相互制約和影響的，有時對這三方面的平衡策略甚至成為一個企業(yè)級的要求，決定了企業(yè)的行為，我們知道 IBM 的軟件是以質(zhì)量為最重要目標的，而微軟的“足夠好的軟件”策略更是耳熟能詳，這些質(zhì)量目標其實立足于企業(yè)的戰(zhàn)略目標。所以用于進行質(zhì)量保證的 SQA 工作也應(yīng)當立足于企

7、業(yè)的戰(zhàn)略目標，從這個角度思考SQA ，形成對 SQA 的理論認識。 軟件界已經(jīng)達成共識的：影響軟件項目進度、成本、質(zhì)量的因素主要是 “人、過程、技術(shù)” 。首先要明確的是這三個因素中，人是第一位的?，F(xiàn)在許多實施 CMM 的人員沉溺于 CMM 的理論過于強調(diào)“過程” ，這是很危險的傾向。這個思想傾向在國外受到了猛烈抨擊，從某種意義上各種敏捷過程方法的提出就是對強調(diào)過程的一種反思。 “ XP ”中的一個思想“人比過程更重要” 是值得我們思考的。我個人的意見在進行過程改進中堅持“以人為本”，強調(diào)過程和人的和諧。根據(jù)現(xiàn)代軟件工程對眾多失敗項目的調(diào)查，發(fā)現(xiàn)管理是項目失敗的主要原因。這個事實的重要性在于說明

8、了 “要保證項目不失敗，我們應(yīng)當更加關(guān)注管理” ，注意這個事實沒有說明另外一個問題“良好的管理可以保證項目的成功” 。現(xiàn)在很多人基于一種粗糙的邏輯，從一個事實反推到的這個結(jié)論，在邏輯上是錯誤的，這種錯誤形成了更加錯誤的做法，這點在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ì)量管理”中的“過程方法” ，并且引

9、入了“統(tǒng)計過程控制”的方法。可以說這兩個思想是CMM 背后的基礎(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í)行、反饋”三個重要方面。QA 的職責就是確保過程的有效執(zhí)行，監(jiān)督項目按照過程進行項目活動；它不負責監(jiān)管產(chǎn)品的質(zhì)量， 不負責向管理層提供項目的情況， 不負責代表管理層進行管理， 只是代表管理層

10、來保證過程的執(zhí)行。3 、 SQA 和其他工作的組合在很多企業(yè)中， 將 SQA 的工作和 QC 、 SEPG 、 組織級的項目管理者的工作混合在一起了，有時甚至更加注重其他方面的工作而沒有做好SQA 的本職工作。根據(jù) hjhza 的意見“中國現(xiàn)在基本有三種 QA （按照工作重點不同來分） ：一是過程改進型，一是配置管理型，一是測試型” 。我個人認為是因為 SQA 工作和其他不同工作組合在一起形成的。 下面根據(jù)本人經(jīng)驗對它們之間的關(guān)系進行一個說明。 4 、 QA 和 QC 兩者基本職責QC ：檢驗產(chǎn)品的質(zhì)量，保證產(chǎn)品符合客戶的需求；是產(chǎn)品質(zhì)量檢查者； QA ：審計過程的質(zhì)量，保證過程被正確執(zhí)行；是

11、過程質(zhì)量審計者； 注意區(qū)別檢查和審計的不同檢查：就是我們常說的找茬，是挑毛病的；審計： 來確認項目按照要求進行的證據(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)系。在這樣的分工原則下， QA 只要檢查項目按照過程進行了某項活動沒有，產(chǎn)出了某個產(chǎn)品沒有；而 QC 來檢查產(chǎn)品是否

12、符合質(zhì)量要求。如果企業(yè)原來具有QC 人員并且 QA 人員配備不足，可以先確定由 QC 兼任 QA 工作。但是只能是暫時的， 獨立的 QA 人員應(yīng)當具備， 因為 QC 工作也是要遵循過程要求的， 也是要被審計過程的， 這種混合情況， 難以保證 QC 工作的過程質(zhì)量。 5 、 QA 和 SEPG 兩者 基本職責SEPG ：制定過程，實施過程改進； QA ： 確保過程被正確執(zhí)行SEPG 應(yīng)當提供過程上的指導，幫助項目組制定項目過程，幫助項目組進行策劃；從而幫助項目組有效的工作， 有效的執(zhí)行過程。 如果項目和QA 對過程的理解發(fā)生爭持， SEPG 作為最終仲裁者。為了進行有效過程改進， SEPG 必須

13、分析項目的數(shù)據(jù)。QA 本也要進行過程規(guī)范，那么所有QA 中最有經(jīng)驗、最有能力的 QA 可以參加 SEPG ，但是要注意這兩者的區(qū)別。如果企業(yè)的 SEPG 人員具有較為深厚的開發(fā)背景，可以兼任 SQA 工作，這樣利于過程的不斷改進； 但是由于立法、 執(zhí)法集于一身也容易造成SQA 過于強勢， 影響項目的獨立性。管理過程比較成熟的企業(yè)，因為企業(yè)的文化和管理機制已經(jīng)健全， SQA 職責范圍的工作較少，往往只是針對具體項目制定明確重點的 SQA 計劃，這樣SQA 的審計工作會大大減少，從而可以同時審計較多項目。另一方面， 由于分工的細致化， 管理體系的復雜化，往往需要專職的 SEPG 人員， 這些人員要

14、求了解企業(yè)的所有管理過程和運作情況，在這個基礎(chǔ)上才能統(tǒng)籌全局的進行過程改進，這時了解全局的 SQA 人員就是專職SEPG 的主要人選；這些SQA 人員將逐漸的轉(zhuǎn)化為SEPG 人員，并且更加了解管理知識，而SQA 工作漸漸成為他們的兼職工作。這種情況在許多 CMM5 企業(yè)比較多見， 往往有時看不見SQA 人員在項目組出現(xiàn)或者很少出現(xiàn)， 這種 SEPG 和 SQA 的融合特別有利于組織的過程改進工作。 SEPG 確定過程改進內(nèi)容， SQA 計劃重點反映這些改進內(nèi)容，從保證有效的改進，特別有利于達到 CMM5 的要求。從這個角度，國外的 SQA 人員為什么高薪就不難理解了，也決定了當前中國 SQA

15、人員比較被輕視的原因；因為管理過程還不完善，我們的 SQA 人員還沒有產(chǎn)生這么大的價值嘛！6 、 QA 和組織級的監(jiān)督管理有的企業(yè)為了更好的監(jiān)督管理項目， 建立了一個角色， 我取名為“ 組織級的監(jiān)督管理者”，他們的職責是對所有項目進行統(tǒng)一的跟蹤、 監(jiān)督、 適當?shù)墓芾恚?來保證管理層對所有項目的可視性、可管理性。 為了有效管理項目， “組織級的監(jiān)督管理者”必須分析項目的數(shù)據(jù)。 他們的職責對照上圖的模型，就是執(zhí)行 “反饋”職能。QA 本身不進行反饋工作，最多對過程執(zhí)行情況的信息進行反饋。SQA 職責最好不要和“組織級的項目管理者”的職責混合在一起，否則容易出現(xiàn)SAQ 困境：一方面SQA 不能準確定

16、位自己的工作，另一方面過程執(zhí)行者對 SQA 人員抱有較大戒心。如果建立了較好的管理過程，那么就會增強項目的可視性，從而保證企業(yè)對所有項目的較好管理；而QA 來確保這個管理過程的運行。5、 SQA 的工作內(nèi)容和工作方法1 、 計劃針對具體項目制定SQA 計劃， 確保項目組正確執(zhí)行過程。 制定 SQA 計劃應(yīng)當注意如下幾點： 有重點：依據(jù)企業(yè)目標以及項目情況確定審計的重點 明確審計內(nèi)容：明確審計哪些活動，那些產(chǎn)品 明確審計方式：確定怎樣進行審計明確審計結(jié)果報告的規(guī)則：審計的結(jié)果報告給誰2 、審計 / 證實依據(jù) SQA 計劃進行 SQA 審計工作，按照規(guī)則發(fā)布審計結(jié)果報告。注意審計一定要有項目組人員

17、陪同，不能搞突然襲擊。雙方要開誠布公，坦誠相對。 審計的內(nèi)容：是否按照過程要求執(zhí)行了相應(yīng)活動，是否按照過程要求產(chǎn)生了相應(yīng)產(chǎn)品。3 、問題跟蹤對審計中發(fā)現(xiàn)的問題，要求項目組改進，并跟進直到解決。6、 SQA 的素質(zhì)過程為中心： 應(yīng)當站在過程的角度來考慮問題， 只要保證了過程， QA 就盡到了責任。 服務(wù)精神：為項目組服務(wù)，幫助項目組確保正確執(zhí)行過程了解過程： 深刻了解企業(yè)的工程， 并具有一定的過程管理理論知識 了解開發(fā)： 對開發(fā)工作的基本情況了解，能夠理解項目的活動溝通技巧：善于溝通，能夠營造良好的氣氛，避免審計活動成為一種找茬活動。7、 SQA 活動軟件質(zhì)量保證（ SQA ）是一種應(yīng)用于整個軟

18、件過程的活動，它包含：1 、一種質(zhì)量管理方法2 、有效的軟件工程技術(shù)（方法和工具）3 、在整個軟件過程中采用的正式技術(shù)評審4 、一種多層次的測試策略5 、對軟件文檔及其修改的控制6 、保證軟件遵從軟件開發(fā)標準7 、度量和報告機制SQA 與兩種不同的參與者相關(guān) 做技術(shù)工作的軟件工程師和負責質(zhì)量保證的計劃、監(jiān)督、記錄、分析及報告工作的 SQA 小組 。軟件工程師通過采用可靠的技術(shù)方法和措施，進行正式的技術(shù)評審，執(zhí)行計劃周密的軟件測試來考慮質(zhì)量問題，并完成軟件質(zhì)量保證和質(zhì)量控制活動。SQA 小組的職責是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。 SQA 小組完成 :（ 1 ）為項目準備SQA 計劃。該計

19、劃在制定項目規(guī)定項目計劃時確定，由所有感興趣的相關(guān)部門評審。需要進行的審計和評審；項目可采用的標準；錯誤報告和跟蹤的規(guī)程； 由SQA小組產(chǎn)生的文檔；向軟件項目組提供的反饋數(shù)量。（ 2 ）參與開發(fā)項目的軟件過程描述。評審過程描述以保證該過程與組織政策，內(nèi)部軟件標準，外界標準以及項目計劃的其他部分相符。（ 3 ）評審各項軟件工程活動，對其是否符合定義好的軟件過程進行核實。記錄、跟蹤與過程的偏差。（ 4 ）審計指定的軟件工作產(chǎn)品，對其是否符合事先定義好的需求進行核實。對產(chǎn)品進行評審， 識別、記錄和跟蹤出現(xiàn)的偏差；對是否已經(jīng)改正進行核實； 定期將工作結(jié)果向項目管理者報告。（ 5 ）確保軟件工作及產(chǎn)品中

20、的偏差已記錄在案，并根據(jù)預定的規(guī)程進行處理。（ 6 ）記錄所有不符合的部分并報告給高級領(lǐng)導者。八、正式技術(shù)評審（ FTR ）正式技術(shù)評審是一種由軟件工程師和其他人進行的軟件質(zhì)量保障活動。1 . 目標：（1） 發(fā)現(xiàn)功能、邏輯或?qū)崿F(xiàn)的錯誤（2） 證實經(jīng)過評審的軟件的確滿足需求（3） 保證軟件的表示符合預定義的標準（4） 得到一種一致的方式開發(fā)的軟件（5） 使項目更易管理2 、評審會議3-5 人參加，不超過2 小時，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個 :（ 1 ）工作產(chǎn)品可不可以不經(jīng)修改而被接受； （ 2 ）由于嚴重錯誤而否決工作產(chǎn)品； （ 3 ）暫時接受工作產(chǎn)品。3 、評審總

21、結(jié)報告、回答評審什么？由誰評審？結(jié)論是什么？評審總結(jié)報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問題的區(qū)域，作為行政條目檢查表以指導生產(chǎn)者進行改正。4 、評審指導原則（ 1 ）評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松。（ 2 ） 不要離題，限制爭論。有異議的問題不要爭論但要記錄在案。（ 3 ）對各個問題都發(fā)表見解。問題解決應(yīng)該放到評審會議之后進行。（ 4 ）為每個要評審的工作產(chǎn)品建立一個檢查表。應(yīng)為分析、設(shè)計、編碼、測試文檔都建立檢查表。（ 5 ）分配資源和時間。應(yīng)該將評審作為軟件工程任務(wù)加以調(diào)度。（ 6 ）評審以前所做的評審九、統(tǒng)計軟件質(zhì)量保證1 、對所有錯誤進行分類統(tǒng)計IES

22、 規(guī)約不完整或規(guī)格說明錯MCC 未理解用戶意圖 IDS 故意偏離規(guī)格說明 VPS 違背編程標準EDR 數(shù)據(jù)表示有錯ICI 構(gòu)件接口不一致 EDL 設(shè)計邏輯有錯IET 測試不完全或有錯IID 不準確或不完整的文檔 PLT 設(shè)計的程序設(shè)計語言翻譯錯 HCI 不清晰或不一致的人機界面MIS 雜項錯誤按嚴重， 一般和微小級別統(tǒng)計各類錯誤的次數(shù)所占百分比， 以及所有錯誤的數(shù)量及百分比。例如，建立一張類似如下的表格。然后考慮“重要少數(shù)”的錯誤指標，提出改進意見。2 、根據(jù)軟件過程中的每個步驟計算錯誤指標。Ei = 第 i 發(fā)現(xiàn)的錯誤總數(shù)Si = 嚴重錯誤數(shù)Mi = 一般錯誤數(shù) Ti = 微小錯誤數(shù)PS =

23、 第 i 步的產(chǎn)品規(guī)模 （ LOC ，設(shè)計陳述，文檔頁數(shù) ）Ws ， Wm ， Wt 分別是嚴重，一般，微小錯誤的加權(quán)因子, 推薦取值， Ws=10 ， Wm=3 ，Wt=1 軟件工程 在過程的每一步中，計算各階段的階段指標PIi = Ws （ Si / Ei ） +Wm（Mi / Ei ） +Wt （Ti / Ei ） 錯誤指標Ei=匯（i x Pli） / PS=（PI1 + 2PI2 + 3PI3 + i*PIi ）/ PS錯誤指標與上面表格中收集的信息相結(jié)合可以得出軟件質(zhì)量整體改進指標。七、 質(zhì)量保證與檢驗 確保每個開發(fā)過程的質(zhì)量， 防止把軟件差錯傳播到下一個過程， 因此，檢驗的目的有

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

25、數(shù)據(jù)設(shè)計-過程設(shè)計檢查：產(chǎn)品的計劃量與實際量；評審量；差錯數(shù)；評審方法，出錯導因及處理情況，階段結(jié)束的判斷標準。3 實現(xiàn)程序編制-單元測試-集成測試-確認測試.檢查內(nèi)容除上述外，加測試環(huán)境及測試用例設(shè)計方法。4 驗收說明書檢查；程序檢查。 1 3 質(zhì)量保證實施軟件質(zhì)量評價標準。1 質(zhì)量需求準則：著眼點是是否滿足用戶的要求2 質(zhì)量設(shè)計準則：開發(fā)者在設(shè)計實現(xiàn)時是否按軟件需求保證了質(zhì)量3 質(zhì)量度量準則：為質(zhì)量度量規(guī)定了一些檢查項目 : 精密度量：根據(jù)質(zhì)量度量準則進行詳細度量全面度量簡易度量五個實施步驟1 Target ：以用戶需求和開發(fā)任務(wù)為依據(jù)，對質(zhì)量需求準則，質(zhì)量設(shè)計準則的質(zhì)量特性設(shè)定質(zhì)量目標進

26、行評價。2 Plan ：設(shè)定適合于待開發(fā)軟件的評測檢查項目，一般設(shè)定20 30 個。3 DO ：在開發(fā)標準和質(zhì)量評價準則的指導下，制作高質(zhì)量的規(guī)格說明書和程序。4 Check ：以 Plan 階段設(shè)定的質(zhì)量評價準則進行評價，算出得分，以質(zhì)量圖的形成表示出來，比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標看其是否合格。5 Action ：對評價發(fā)現(xiàn)的問題進行改進活動，重復Plan 到 Action 的過程直到開發(fā)項目完成。 1 4 軟件可靠性可靠性統(tǒng)計定義：在給定的環(huán)境和給定的時間間隔內(nèi)，按設(shè)計要求成功運行程序的概率。 二、軟件可靠性的主要指標MTBF 平均故障間隔時間 MTTF 平均故障時間 MTTR 平均修復時間 MTBF = MTTF + MTTR軟件可用性是指在某個給定時間點程序能夠按照需求執(zhí)行的概率。 可用性 = MTTF /（MTTF+MTTR ） X 100% 1 . 5 ISO9000質(zhì)量標準ISO900