【正文】 ”質(zhì)量保證的能力是成熟的工程學(xué)科的量尺。 ? 為了正確的進(jìn)行軟件質(zhì)量保證，必須收集、評估和發(fā)布軟件工程過程的數(shù)據(jù)。但是當(dāng)被更為一般地考慮時(shí)，軟件質(zhì)量包括了許多不同的產(chǎn)品和過程因素及其相關(guān)的度量。 ? “ SQA計(jì)劃”的其他部分標(biāo)識了支持 SQA活動與任務(wù)的工具和方法；給出了控制變化的軟件配置管理過程；定義了一種合同管理方法；建立了組裝、保護(hù)、維護(hù)所有記錄的方法；標(biāo)識了為滿足這一計(jì)劃所需的培訓(xùn)；定義了標(biāo)識、評估、監(jiān)控和控制風(fēng)險(xiǎn)的方法。它給出了各種復(fù)審和審計(jì)方法的總覽。 ? “文檔”一節(jié)（通過引用）描述的是軟件過程各個(gè)部分所產(chǎn)生的各種工作產(chǎn)品，包括： * 項(xiàng)目文檔 （例如項(xiàng)目計(jì)劃） * 模型 （例如 ERD模型、類層次模型） * 技術(shù)文檔 （例如規(guī)約、測試計(jì)劃） * 用戶文檔 （例如幫助文件） ? 另外，在這一節(jié)中還定義了實(shí)現(xiàn)高質(zhì)量所能接受的工作產(chǎn)品的最小集合。 ? SQA計(jì)劃的標(biāo)準(zhǔn)由 IEEE 推薦。 ? ISO 9001描述的需求強(qiáng)調(diào)了管理責(zé)任、質(zhì)量系統(tǒng)、控制復(fù)審、設(shè)計(jì)控制、文檔和數(shù)據(jù)控制、產(chǎn)品標(biāo)識和跟蹤、過程控制、審查和測試、糾正和預(yù)防性動作、控制質(zhì)量記錄、內(nèi)部質(zhì)量審計(jì)、培訓(xùn)、服務(wù)以及統(tǒng)計(jì)技術(shù)的話題 。 ? KEYPOINT： ISO 9000描述必須做什么以保證符合，但是，它并沒有描述必須如何做。 ? ISO 9000以一般術(shù)語描述了一個(gè)質(zhì)量保證系統(tǒng)的元素。 ? 成功登記之后，這一公司將收到由審計(jì)者所代表的登記實(shí)體頒發(fā)的證書。電信設(shè)備和醫(yī)療設(shè)備是必須由 ISO登記公司供應(yīng)的產(chǎn)品類別的例子。 ISO 9000質(zhì)量標(biāo)準(zhǔn) The ISO 9000 Quality Standards ? “質(zhì)量保證系統(tǒng) ”可以被定義成用于實(shí)現(xiàn)質(zhì)量管理的組織結(jié)構(gòu)、責(zé)任、規(guī)程、過程和資源 。 * 是過程的一部分 。 Shingo的概念使用 pokayoke設(shè)備， 用于： （ 1）潛在質(zhì)量問題發(fā)生前的預(yù)防； （ 2）質(zhì)量問題的快速探測。 ? 盡管軟件可靠性與軟件安全性相互之間關(guān)系緊密，但是理解它們之間的微妙差異更為重要。 例如 ，一個(gè)微小的用戶輸入錯(cuò)誤可能被軟件錯(cuò)誤放大成產(chǎn)生將機(jī)械設(shè)備置于不正確位置的控制數(shù)據(jù)。 ? 建模和分析過程可以視為軟件安全性的一部分。其定義為： 可用性 ＝ MTTF / (MTTF ＋ MTTR) 100％ ? MTBF可靠性度量對 MTTF和 MTTR同樣敏感。 ? 還有一些尚未被發(fā)現(xiàn)的缺陷的失敗率可能是 18或24個(gè)月。 簡而言之，最終用戶關(guān)心的是失效，而不是總?cè)毕輸?shù)。 ? 故障是物理地或靜態(tài)地存在的 ? 失誤、錯(cuò)誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象 ? 軟件發(fā)生失效標(biāo)志著軟件一次使用壽命的結(jié)束 ? 發(fā)生過失效的軟件通常仍然是可用的。 ? 故障 /缺陷 (fault)：故障是錯(cuò)誤的結(jié)果，或錯(cuò)誤的表現(xiàn)。 舉例說明 ，程序 X在 8個(gè)小時(shí)處理占用時(shí)間中的可靠性估計(jì)為 ；也就是說，如果程序 X執(zhí)行100次，每次運(yùn)行 8個(gè)小時(shí)的處理占用時(shí)間（執(zhí)行時(shí)間），則 100次中正確運(yùn)行（不失?。┑拇螖?shù)可能是 96。 ? 在軟件工程過程中的每一步中，分別計(jì)算各個(gè)階段的階段指標(biāo)（ phase index） PIi： PIi = Ws (Si/Ei) + Wm (Mi/Ei) + Wt (Ti/Ei) ? 錯(cuò)誤指標(biāo) EI通過計(jì)算各個(gè) PIi的加權(quán)效果得到，在軟件工程過程中后面的步驟中遇到的錯(cuò)誤的權(quán)重要高于在前面階段遇到的錯(cuò)誤權(quán)重。 ? 當(dāng)與缺陷信息集合結(jié)合使用時(shí)，軟件開發(fā)者可以為軟件工程過程中的每個(gè)步驟計(jì)算“錯(cuò)誤指標(biāo)”（ Error index， EI）。 所有錯(cuò)誤都可以追溯到下述原因中的一個(gè) (或幾個(gè) ): * 規(guī)約不完整或規(guī)約錯(cuò)誤 （ inplete or erroneous specifications， IES） * 與客戶通信中所產(chǎn)生的誤解 （ misinterpretation of customer munication， MCC） * 故意與規(guī)約偏離 （ intentional deviation from specification， IDS） * 違反編程標(biāo)準(zhǔn) （ violation of programming standards，VPS） * 數(shù)據(jù)表示有錯(cuò) （ error in data representation， EDR） * 構(gòu)件接口不一致 （ inconsistent ponent interface，ICI） * 設(shè)計(jì)邏輯有錯(cuò) （ error in design logic， EDL） * 不完整或錯(cuò)誤的測試 （ inplete or erroneous testing， IET） * 不準(zhǔn)確或不完整的文檔 （ inaccurate or inplete documentation， IID） * 將設(shè)計(jì)翻譯成程序設(shè)計(jì)語言中的錯(cuò)誤 （ error in programming language translation of design， PLT） * 不清晰或不一致的人機(jī)界面 （ ambiguous or inconsistent human/puter interface， HCI） * 雜項(xiàng) （ miscellaneous， MIS） 表 81 ? 重要的是要注意，糾正性動作主要注重于“重要的少數(shù)”。對于軟件而言， 統(tǒng)計(jì)質(zhì)量保證包括以下步驟： 1. 收集和分類軟件缺陷信息。 ? 一旦需求模型（規(guī)約）和程序設(shè)計(jì)語言以一種嚴(yán)格的方式被表達(dá)出來，就可以采用程序正確性的數(shù)學(xué)證明來說明程序是否嚴(yán)格符合它的規(guī)約。 由于成功的復(fù)審涉及到許多變數(shù)（ 如，參與者數(shù)量、工作產(chǎn)品類型、時(shí)間和長度、特定的復(fù)審方法等） ，軟件組織應(yīng)該在實(shí)驗(yàn)中決定何種方法最為適用。為了提高效率，所有復(fù)審參與者都應(yīng)該接受某種正式培訓(xùn)。 8. 為 FTR分配資源和時(shí)間 。 6. 限制參與者人數(shù)并堅(jiān)持事先作準(zhǔn)備 。復(fù)審不是一個(gè)問題解決會議。 3. 限制爭論和辯駁 。 2. 制定日程并且遵守日程 。 FTR涉及到別人和自我。 復(fù)審指南 Review Guidelines 進(jìn)行正式技術(shù)復(fù)審之前必須建立復(fù)審指南，分發(fā)給所有復(fù)審者，并得到大家的認(rèn)可，然后才能依照它進(jìn)行復(fù)審。它是項(xiàng)目歷史記錄的一部分，有可能被分發(fā)給項(xiàng)目管理者和其他感興趣的參與方。 復(fù)審報(bào)告和記錄保存 Review Reporting and Record Keeping ? 在 FTR期間，一名復(fù)審者（記錄員）主動記錄所有提出的問題。 例如 ，不要試圖復(fù)審整個(gè)設(shè)計(jì)，而是對每個(gè)模塊或者一小組模塊進(jìn)行走查。由于 FTR的進(jìn)行使大量人員對軟件系統(tǒng)中原本并不熟悉的部分更為了解，因此， FTR還起到了提高項(xiàng)目連續(xù)性和培訓(xùn)后備人員的作用。 ? （設(shè)計(jì)和其他技術(shù)活動中的）正式技術(shù)復(fù)審提供了顯而易見的成本效益。 ? 而在不進(jìn)行復(fù)審的情況下，總成本是 2177個(gè)成本單位。 缺陷的放大和消除 Defect Amplification and Removal ? 可以用“缺陷放大模型” [IBM81]來說明在軟件工程過程中的概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和編碼階段中錯(cuò)誤的產(chǎn)生及檢測。 ? 而現(xiàn)有研究表明 正式技術(shù)復(fù)審在發(fā)現(xiàn)設(shè)計(jì)錯(cuò)誤方面最高達(dá)到 75％的有效性 。它們