一、基本目標

      目標 1: 軟件質(zhì)量保證工作是有計劃進(jìn)行的。
      目標 2: 客觀(guān)地驗證軟件項目產(chǎn)品和工作是否遵循恰當的標準、步驟和需求。
      目標 3: 將軟件質(zhì)量保證工作及結果通知給相關(guān)組別和個(gè)人。
      目標 4: 高級管理層接觸到在項目?jì)炔坎荒芙鉀Q的不符合類(lèi)問(wèn)題。
 
二、QA的由來(lái)

      我們知道，國外很多的大公司，QA的職責就是測試（主要是系統測試），比如IBM、CA、PeoplESoft等。其實(shí)在最初，幾乎所有的公司都是這樣的。后來(lái)，由于缺乏有效的項目計劃和項目管理，留給系統測試的時(shí)間很少（注：我以前做的一個(gè)項目，項目經(jīng)理就明確告訴我系統測試就1天，沒(méi)得商量）。另外，需求變化太快，沒(méi)有完整的需求文檔，測試人員就只能根據自己的想象來(lái)測試。這樣一來(lái)，測試就很難保障產(chǎn)品的質(zhì)量，事先預防的QA職能就應運而生。
事先預防其實(shí)是借鑒了TQM的思想，而且也符合軟件工程“缺陷越早發(fā)現越早修改越經(jīng)濟”的原則。這些思想的淵源還可以追溯到中國古代的典故中，比如曲突徙薪、扁鵲論醫術(shù)等。特別是扁鵲論醫術(shù)這個(gè)典故，我偶然在國外的一篇文章中看到了（后來(lái)在林銳的文章中也看到了），常感嘆我們國人連祖先的思想文化遺產(chǎn)都丟的差不多了。

三、QA的現在

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

      缺乏信任和支持只是一個(gè)方面，QA工作本身就很具挑戰性。它要求QA具有軟件工程的知識、軟件開(kāi)發(fā)的知識、行業(yè)背景的知識、數理統計的知識、項目管理的知識、質(zhì)量管理的知識等等。

      我們常常遇到這樣的問(wèn)題，改進(jìn)到一定程度就很難突破，感覺(jué)心有余而力不足了，就開(kāi)始郁悶了。后來(lái)通過(guò)學(xué)習、培訓、交流，思想和技能得到升華，又發(fā)現了木桶中最短的那塊，然后又開(kāi)始改進(jìn)，然后又遇到了玻璃天花板，然后……就這樣處于郁悶的循環(huán)中。
 
      假使我們掌握了所有的知識，能突破所有的玻璃天花板，那是不是QA就可以一帆風(fēng)順了。答案是否定的。QA角色定義本身就有很大的局限性。QA充當的是過(guò)程警察的角色，無(wú)論是否有意義，都專(zhuān)橫地強制過(guò)程的執行，容易在項目組中造成敵對的關(guān)系，受到排擠，而且這種警察的姿態(tài)也破壞了團隊精神。如此一來(lái)，QA工作還需要的是人際關(guān)系技能，就如我以前寫(xiě)的《質(zhì)量平衡》和《QA應該獨立于項目組嗎？》一樣，藝術(shù)化地處理這種關(guān)系。

四、QA的未來(lái)

      從某種程度上說(shuō)，獨立的QA審查機制是瀑布模型的產(chǎn)物。隨著(zhù)現代軟件開(kāi)發(fā)技術(shù)的演變，螺旋模型和迭代模型的興起，QA機制正在悄然發(fā)生變化。這種變化就是從獨立專(zhuān)職的QA向貫穿過(guò)程的兼職QA演變。在CMMI模型中，這種兼職的QA也是被允許的。為什么會(huì )發(fā)生這種改變呢？無(wú)論是XP、RUP還是其它先進(jìn)的方法論，都是先產(chǎn)生架構，然后再增量開(kāi)發(fā)，直到完成。這種模式中，需求和設計缺陷在各個(gè)迭代周期被所盡早發(fā)現和修復，質(zhì)量也內建于架構和過(guò)程中，項目的成本和進(jìn)度也得到保障。
到那時(shí)，是不是獨立的QA就不復存在了呢？有些成熟度較低的企業(yè)還是需要的，主要是保證過(guò)程執行的有效性和評價(jià)的客觀(guān)性。

五、SQA的理論探索

      1、過(guò)程的認識

      我們都知道一個(gè)項目的主要內容是：成本、進(jìn)度、質(zhì)量；良好的項目管理就是綜合三方面的因素，平衡三方面的目標，最終依照目標完成任務(wù)。項目的這三個(gè)方面是相互制約和影響的，有時(shí)對這三方面的平衡策略甚至成為一個(gè)企業(yè)級的要求，決定了企業(yè)的行為，我們知道 IBM的軟件是以質(zhì)量為最重要目標的，而微軟的“足夠好的軟件”策略更是耳熟能詳，這些質(zhì)量目標其實(shí)立足于企業(yè)的戰略目標。所以用于進(jìn)行質(zhì)量保證的SQA工作也應當立足于企業(yè)的戰略目標，從這個(gè)角度思考SQA，形成對SQA的理論認識。

      軟件界已經(jīng)達成共識的：影響軟件項目進(jìn)度、成本、質(zhì)量的因素主要是 “人、過(guò)程、技術(shù)”。首先要明確的是這三個(gè)因素中，人是第一位的。

      現在許多實(shí)施 CMM的人員沉溺于CMM的理論過(guò)于強調“過(guò)程”，這是很危險的傾向。這個(gè)思想傾向在國外受到了猛烈抨擊，從某種意義上各種敏捷過(guò)程方法的提出就是對強調過(guò)程的一種反思。 “XP”中的一個(gè)思想“人比過(guò)程更重要” 是值得我們思考的。我個(gè)人的意見(jiàn)在進(jìn)行過(guò)程改進(jìn)中堅持“以人為本”，強調過(guò)程和人的和諧。

      根據現代軟件工程對眾多失敗項目的調查，發(fā)現管理是項目失敗的主要原因。這個(gè)事實(shí)的重要性在于說(shuō)明了 “要保證項目不失敗，我們應當更加關(guān)注管理”，注意這個(gè)事實(shí)沒(méi)有說(shuō)明另外一個(gè)問(wèn)題“良好的管理可以保證項目的成功”?，F在很多人基于一種粗糙的邏輯，從一個(gè)事實(shí)反推到的這個(gè)結論，在邏輯上是錯誤的，這種錯誤形成了更加錯誤的做法，這點(diǎn)在SQA的理解上是體現較深。

      如果我們考證一下歷史的沿革，應當更加容易理解 CMM的本質(zhì)。CMM首先是作為一個(gè)“評估標準”出現的，主要評估的是美國國防部供應商保證質(zhì)量的能力。CMM關(guān)注的軟件生產(chǎn)有如下特點(diǎn)：
      （1）質(zhì)量重要
      （2）規模較大

      這是 CMM產(chǎn)生的原因。它引入了“全面質(zhì)量管理”的思想，尤其側重了“全面質(zhì)量管理”中的“過(guò)程方法”，并且引入了“統計過(guò)程控制”的方法?？梢哉f(shuō)這兩個(gè)思想是CMM背后的基礎。

      上面這些內容形成了我對軟件過(guò)程地位、價(jià)值的基本理解；在這個(gè)基礎上我們可以引申討論 SQA。

      2、生產(chǎn)線(xiàn)的隱喻

      如果將一個(gè)軟件生產(chǎn)類(lèi)比于一個(gè)工廠(chǎng)的生產(chǎn)。那么生產(chǎn)線(xiàn)就是過(guò)程，產(chǎn)品按照生產(chǎn)線(xiàn)的規定過(guò)程進(jìn)行生產(chǎn)。 SQA的職責就是保證過(guò)程的執行，也就是保證生產(chǎn)線(xiàn)的正常執行。

      抽象出管理體系模型的如下，這個(gè)模型說(shuō)明了一個(gè)過(guò)程體系至少應當包含 “決策、執行、反饋”三個(gè)重要方面。

      QA的職責就是確保過(guò)程的有效執行，監督項目按照過(guò)程進(jìn)行項目活動(dòng)；它不負責監管產(chǎn)品的質(zhì)量，不負責向管理層提供項目的情況，不負責代表管理層進(jìn)行管理，只是代表管理層來(lái)保證過(guò)程的執行。

      3、SQA和其他工作的組合

      在很多企業(yè)中，將 SQA的工作和QC、SEPG、組織級的項目管理者的工作混合在一起了，有時(shí)甚至更加注重其他方面的工作而沒(méi)有做好SQA的本職工作。

      根據 hjhza 的意見(jiàn)“中國現在基本有三種QA（按照工作重點(diǎn)不同來(lái)分）：一是過(guò)程改進(jìn)型，一是配置管理型，一是測試型”。我個(gè)人認為是因為SQA工作和其他不同工作組合在一起形成的。

      下面根據本人經(jīng)驗對它們之間的關(guān)系進(jìn)行一個(gè)說(shuō)明。

      4、QA和QC

      兩者基本職責

      QC：檢驗產(chǎn)品的質(zhì)量，保證產(chǎn)品符合客戶(hù)的需求；是產(chǎn)品質(zhì)量檢查者；
      QA：審計過(guò)程的質(zhì)量，保證過(guò)程被正確執行；是過(guò)程質(zhì)量審計者；

      注意區別檢查和審計的不同

      檢查：就是我們常說(shuō)的找茬，是挑毛病的；

      審計：來(lái)確認項目按照要求進(jìn)行的證據；仔細看看CMM中各個(gè)KPA中SQA的檢查采用的術(shù)語(yǔ)大量用到了“證實(shí)”，審計的內容主要是過(guò)程的；對照CMM看一下項目經(jīng)理和高級管理者的審查內容，他們更加關(guān)注具體內容。

      對照上面的管理體系模型，QC進(jìn)行質(zhì)量控制，向管理層反饋質(zhì)量信息；QA則確保QC按照過(guò)程進(jìn)行質(zhì)量控制活動(dòng)，按照過(guò)程將檢查結果向管理層匯報。這就是QA和QC工作的關(guān)系。

      在這樣的分工原則下， QA只要檢查項目按照過(guò)程進(jìn)行了某項活動(dòng)沒(méi)有，產(chǎn)出了某個(gè)產(chǎn)品沒(méi)有；而QC來(lái)檢查產(chǎn)品是否符合質(zhì)量要求。

      如果企業(yè)原來(lái)具有 QC人員并且QA人員配備不足，可以先確定由QC兼任QA工作。但是只能是暫時(shí)的，獨立的QA人員應當具備，因為QC工作也是要遵循過(guò)程要求的，也是要被審計過(guò)程的，這種混合情況，難以保證QC工作的過(guò)程質(zhì)量。

      5、QA和SEPG

      兩者基本職責

      SEPG：制定過(guò)程，實(shí)施過(guò)程改進(jìn)；
      QA： 確保過(guò)程被正確執行

      SEPG應當提供過(guò)程上的指導，幫助項目組制定項目過(guò)程，幫助項目組進(jìn)行策劃；從而幫助項目組有效的工作，有效的執行過(guò)程。如果項目和QA對過(guò)程的理解發(fā)生爭持，SEPG作為最終仲裁者。為了進(jìn)行有效過(guò)程改進(jìn)，SEPG必須分析項目的數據。

      QA本也要進(jìn)行過(guò)程規范，那么所有QA中最有經(jīng)驗、最有能力的QA可以參加SEPG，但是要注意這兩者的區別。

      如果企業(yè)的 SEPG人員具有較為深厚的開(kāi)發(fā)背景，可以兼任SQA工作，這樣利于過(guò)程的不斷改進(jìn)；但是由于立法、執法集于一身也容易造成SQA過(guò)于強勢，影響項目的獨立性。

      管理過(guò)程比較成熟的企業(yè)，因為企業(yè)的文化和管理機制已經(jīng)健全， SQA職責范圍的工作較少，往往只是針對具體項目制定明確重點(diǎn)的SQA計劃，這樣SQA的審計工作會(huì )大大減少，從而可以同時(shí)審計較多項目。

      另一方面，由于分工的細致化，管理體系的復雜化，往往需要專(zhuān)職的 SEPG人員，這些人員要求了解企業(yè)的所有管理過(guò)程和運作情況，在這個(gè)基礎上才能統籌全局的進(jìn)行過(guò)程改進(jìn)，這時(shí)了解全局的SQA人員就是專(zhuān)職SEPG的主要人選；這些SQA人員將逐漸的轉化為SEPG人員，并且更加了解管理知識，而SQA工作漸漸成為他們的兼職工作。

      這種情況在許多 CMM5企業(yè)比較多見(jiàn)，往往有時(shí)看不見(jiàn)SQA人員在項目組出現或者很少出現，這種SEPG和SQA的融合特別有利于組織的過(guò)程改進(jìn)工作。SEPG確定過(guò)程改進(jìn)內容，SQA計劃重點(diǎn)反映這些改進(jìn)內容，從保證有效的改進(jìn)，特別有利于達到CMM5的要求。從這個(gè)角度，國外的SQA人員為什么高薪就不難理解了，也決定了當前中國SQA人員比較被輕視的原因；因為管理過(guò)程還不完善，我們的SQA人員還沒(méi)有產(chǎn)生這么大的價(jià)值嘛！

      6、QA和組織級的監督管理

      有的企業(yè)為了更好的監督管理項目，建立了一個(gè)角色，我取名為 “組織級的監督管理者”，他們的職責是對所有項目進(jìn)行統一的跟蹤、監督、適當的管理，來(lái)保證管理層對所有項目的可視性、可管理性。

      為了有效管理項目， “組織級的監督管理者”必須分析項目的數據。

      他們的職責對照上圖的模型，就是執行 “反饋”職能。
 
      QA本身不進(jìn)行反饋工作，最多對過(guò)程執行情況的信息進(jìn)行反饋。

      SQA職責最好不要和“組織級的項目管理者”的職責混合在一起，否則容易出現SAQ困境：一方面SQA不能準確定位自己的工作，另一方面過(guò)程執行者對SQA人員抱有較大戒心。

      如果建立了較好的管理過(guò)程，那么就會(huì )增強項目的可視性，從而保證企業(yè)對所有項目的較好管理；而 QA來(lái)確保這個(gè)管理過(guò)程的運行。

五、SQA的工作內容和工作方法

      1、 計劃

      針對具體項目制定 SQA計劃，確保項目組正確執行過(guò)程。制定SQA計劃應當注意如下幾點(diǎn)：

      有重點(diǎn)：依據企業(yè)目標以及項目情況確定審計的重點(diǎn)
      明確審計內容：明確審計哪些活動(dòng)，那些產(chǎn)品
      明確審計方式：確定怎樣進(jìn)行審計
      明確審計結果報告的規則：審計的結果報告給誰(shuí)

      2、審計/證實(shí)

      依據 SQA計劃進(jìn)行SQA審計工作，按照規則發(fā)布審計結果報告。

      注意審計一定要有項目組人員陪同，不能搞突然襲擊。雙方要開(kāi)誠布公，坦誠相對。

      審計的內容：是否按照過(guò)程要求執行了相應活動(dòng)，是否按照過(guò)程要求產(chǎn)生了相應產(chǎn)品。

      3、問(wèn)題跟蹤

      對審計中發(fā)現的問(wèn)題，要求項目組改進(jìn)，并跟進(jìn)直到解決。

六、SQA的素質(zhì)

      過(guò)程為中心：應當站在過(guò)程的角度來(lái)考慮問(wèn)題，只要保證了過(guò)程， QA就盡到了責任。

      服務(wù)精神：為項目組服務(wù)，幫助項目組確保正確執行過(guò)程

      了解過(guò)程：深刻了解企業(yè)的工程，并具有一定的過(guò)程管理理論知識

      了解開(kāi)發(fā)：對開(kāi)發(fā)工作的基本情況了解，能夠理解項目的活動(dòng)

      溝通技巧：善于溝通，能夠營(yíng)造良好的氣氛，避免審計活動(dòng)成為一種找茬活動(dòng)。

七、SQA活動(dòng)

      軟件質(zhì)量保證（SQA）是一種應用于整個(gè)軟件過(guò)程的活動(dòng)，它包含：
      1、一種質(zhì)量管理方法
      2、有效的軟件工程技術(shù)（方法和工具）
      3、在整個(gè)軟件過(guò)程中采用的正式技術(shù)評審
      4、一種多層次的測試策略
      5、對軟件文檔及其修改的控制
      6、保證軟件遵從軟件開(kāi)發(fā)標準
      7、度量和報告機制

   SQA與兩種不同的參與者相關(guān) —— 做技術(shù)工作的軟件工程師和負責質(zhì)量保證的計劃、監督、記錄、分析及報告工作的SQA小組 。

   軟件工程師通過(guò)采用可靠的技術(shù)方法和措施，進(jìn)行正式的技術(shù)評審，執行計劃周密的軟件測試來(lái)考慮質(zhì)量問(wèn)題，并完成軟件質(zhì)量保證和質(zhì)量控制活動(dòng)。

   SQA小組的職責是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。SQA小組完成:

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

八、正式技術(shù)評審（FTR）

  正式技術(shù)評審是一種由軟件工程師和其他人進(jìn)行的軟件質(zhì)量保障活動(dòng)。

1. 目標：
(1) 發(fā)現功能、邏輯或實(shí)現的錯誤
(2) 證實(shí)經(jīng)過(guò)評審的軟件的確滿(mǎn)足需求
(3) 保證軟件的表示符合預定義的標準
(4) 得到一種一致的方式開(kāi)發(fā)的軟件
(5) 使項目更易管理

2、評審會(huì )議
3-5人參加，不超過(guò)2小時(shí)，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個(gè) :
（1）工作產(chǎn)品可不可以不經(jīng)修改而被接受；
（2）由于嚴重錯誤而否決工作產(chǎn)品；
（3）暫時(shí)接受工作產(chǎn)品。

3、評審總結報告、回答
評審什么？由誰(shuí)評審？結論是什么？
評審總結報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問(wèn)題的區域，作為行政條目檢查表以指導生產(chǎn)者進(jìn)行改正。

4、評審指導原則
（1）評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松。
（2）不要離題，限制爭論。有異議的問(wèn)題不要爭論但要記錄在案。
（3）對各個(gè)問(wèn)題都發(fā)表見(jiàn)解。問(wèn)題解決應該放到評審會(huì )議之后進(jìn)行。
（4）為每個(gè)要評審的工作產(chǎn)品建立一個(gè)檢查表。應為分析、設計、編碼、測試文檔都建立檢查表。
（5）分配資源和時(shí)間。應該將評審作為軟件工程任務(wù)加以調度。
（6）評審以前所做的評審

九、統計軟件質(zhì)量保證

1、對所有錯誤進(jìn)行分類(lèi)統計
IES    規約不完整或規格說(shuō)明錯
MCC  未理解用戶(hù)意圖
IDS    故意偏離規格說(shuō)明
VPS    違背編程標準
EDR    數據表示有錯
ICI     構件接口不一致
EDL    設計邏輯有錯
IET     測試不完全或有錯
IID     不準確或不完整的文檔
PLT     設計的程序設計語(yǔ)言翻譯錯
HCI     不清晰或不一致的人機界面
MIS     雜項錯誤
按嚴重，一般和微小級別統計各類(lèi)錯誤的次數所占百分比，以及所有錯誤的數量及百分比。例如，建立一張類(lèi)似如下的表格。

 然后考慮“重要少數”的錯誤指標，提出改進(jìn)意見(jiàn)。

2、根據軟件過(guò)程中的每個(gè)步驟計算錯誤指標。

Ei = 第i發(fā)現的錯誤總數
Si = 嚴重錯誤數
Mi = 一般錯誤數
Ti = 微小錯誤數
PS = 第i步的產(chǎn)品規模( LOC，設計陳述，文檔頁(yè)數)
Ws，Wm，Wt分別是嚴重，一般，微小錯誤的加權因子, 推薦取值，Ws=10，Wm=3，Wt=1
軟件工程 在過(guò)程的每一步中，計算各階段的階段指標
PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）
錯誤指標
Ei= ∑（i×PIi）/ PS
  =（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS
錯誤指標與上面表格中收集的信息相結合可以得出軟件質(zhì)量整體改進(jìn)指標。七、質(zhì)量保證與檢驗
確保每個(gè)開(kāi)發(fā)過(guò)程的質(zhì)量，防止把軟件差錯傳播到下一個(gè)過(guò)程，因此，檢驗的目的有兩個(gè)：
1．切實(shí)搞好開(kāi)發(fā)階段的管理，檢查各開(kāi)發(fā)階段的質(zhì)量保證。
2．預先防止軟件差錯給用戶(hù)造成損失。

檢驗的類(lèi)型有:
1．供貨檢驗：對委托外單位承擔開(kāi)發(fā)作業(yè)，而后買(mǎi)進(jìn)或轉讓的構成軟件產(chǎn)品的部件，規格說(shuō)明，半成品或產(chǎn)品的檢查。
2．中間檢驗 / 階段評審
目的是為了判斷是否可進(jìn)入下階段進(jìn)行后續開(kāi)發(fā)，避免將差錯傳播到后續工作中。
3．驗收檢驗：
確認產(chǎn)品是否已達到可以進(jìn)行產(chǎn)品檢驗的質(zhì)量要求。
4．產(chǎn)品檢驗：
判定向用戶(hù)提供的軟件產(chǎn)品是否達到令人滿(mǎn)意的程度。

十、檢驗項目?jì)热?/strong>

1．需求分析
需求分析→功能設計→實(shí)施計劃
檢查：開(kāi)發(fā)目的；目標值；開(kāi)發(fā)量；所需資源；各階段的產(chǎn)品作業(yè)內容及開(kāi)發(fā)體制的合理性。
2．設計
結構設計→數據設計→過(guò)程設計
檢查：產(chǎn)品的計劃量與實(shí)際量；評審量；差錯數；評審方法，出錯導因及處理情況，階段結束的判斷標準。
3．實(shí)現
程序編制→單元測試→集成測試→確認測試.檢查內容除上述外，加測試環(huán)境及測試用例設計方法。
4．驗收
說(shuō)明書(shū)檢查；程序檢查。

1．3質(zhì)量保證實(shí)施

      軟件質(zhì)量評價(jià)標準。
1．質(zhì)量需求準則：著(zhù)眼點(diǎn)是是否滿(mǎn)足用戶(hù)的要求
2．質(zhì)量設計準則：開(kāi)發(fā)者在設計實(shí)現時(shí)是否按軟件需求保證了質(zhì)量
3．質(zhì)量度量準則：為質(zhì)量度量規定了一些檢查項目:
   精密度量：根據質(zhì)量度量準則進(jìn)行詳細度量
   全面度量
   簡(jiǎn)易度量

      五個(gè)實(shí)施步驟
1．Target：以用戶(hù)需求和開(kāi)發(fā)任務(wù)為依據，對質(zhì)量需求準則，質(zhì)量設計準則的質(zhì)量特性設定質(zhì)量目標進(jìn)行評價(jià)。
2．Plan：設定適合于待開(kāi)發(fā)軟件的評測檢查項目，一般設定20—30個(gè)。
3．DO：在開(kāi)發(fā)標準和質(zhì)量評價(jià)準則的指導下，制作高質(zhì)量的規格說(shuō)明書(shū)和程序。
4．ChECk：以Plan階段設定的質(zhì)量評價(jià)準則進(jìn)行評價(jià)，算出得分，以質(zhì)量圖的形成表示出來(lái)，比較評價(jià)結果的質(zhì)量得分和質(zhì)量目標看其是否合格。
5．Action：對評價(jià)發(fā)現的問(wèn)題進(jìn)行改進(jìn)活動(dòng)，重復Plan到Action的過(guò)程直到開(kāi)發(fā)項目完成。

1．4  軟件可靠性

      可靠性統計定義：
在給定的環(huán)境和給定的時(shí)間間隔內，按設計要求成功運行程序的概率。
二、軟件可靠性的主要指標
MTBF —— 平均故障間隔時(shí)間
MTTF —— 平均故障時(shí)間
MTTR —— 平均修復時(shí)間
MTBF = MTTF + MTTR
軟件可用性是指在某個(gè)給定時(shí)間點(diǎn)程序能夠按照需求執行的概率。
可用性 = MTTF /（MTTF+MTTR）×100%

1．5   ISO9000 質(zhì)量標準

ISO9000標準被很多國家采用，包括歐盟的所有成員，加拿大、墨西哥、美國、澳大利亞、新西蘭和太平洋區域。為了注冊成為ISO9000中包含的質(zhì)量保證系統模型中的一種，一個(gè)公司的質(zhì)量系統和操作應該由第三方審計者仔細檢查，查看其標準的符合性以及操作的有效性。成功注冊之后，這一公司將收到由審計者所代表的注冊實(shí)體頒發(fā)的證書(shū)。此后，每半年進(jìn)行一次檢查性審計。
ISO9001是應用于軟件工程質(zhì)量保證標準。這一標準中包含了高效的質(zhì)量保證系統必須體現的20條需求。因為ISO9001標準，適用于所有的工程行業(yè)，因此，為幫助解釋該標準在軟件過(guò)程中的使用而專(zhuān)門(mén)開(kāi)發(fā)了一個(gè)ISO指南的子集ISO9000—3。
ISO9001描述的需求涉及到管理責任，質(zhì)量系統，合約評審，設計控制，文檔和數據控制，產(chǎn)品標識和跟蹤，過(guò)程和控制，審查和測試，糾正和預防性動(dòng)作，質(zhì)量控制記錄，內部質(zhì)量審計，培訓，服務(wù)以及統計技術(shù)的主題。