【正文】 據(jù)的對應關系 ? 評價準則 ? 所有邏輯數(shù)據(jù)都與物理數(shù)據(jù)對應 ? 對應于一個物理數(shù)據(jù)的邏輯數(shù)據(jù)數(shù)（以一對一為好） 55 ? 結(jié)構(gòu)特性 功能與模塊的對應關系 ? 評價準則 ? 所有功能都與模塊對應 ? 對應模塊的功能個數(shù)（以一對 一為好） 56 軟件可靠性 ? 軟件生存期與軟件壽命的關系 ? 在軟件工程中常用的定義 ? 軟件可靠性定義 ? 測試中的可靠性分析 ? 測試精確度和測試覆蓋度的評價 57 軟件生存期與軟件壽命的關系 ? 一切有生命的東西都有一個“ 壽命 ” ? 這個概念也可以延伸到對非生命產(chǎn)品的質(zhì)量評價上來。 ? 希望用一個指標 平均失效間隔時間 MTBF(MeanTime Between Failure) 來表明，在規(guī)定的要求和條件下，能在多大的程度上依賴這個軟件來完成任務。而做一個大的課題時，由于程序連續(xù)出錯， MTBF就會變得很短。 ? 它指的可能是 bug(設計中的差錯 )、 fault(故障 )、 error(錯誤 )、 failure(失效 )、crash(重大事故 )、 problem(疑問 )等。 ? 錯誤 (error)： 故障在一定的環(huán)境條件下的暴露 ，導致系統(tǒng)在運行中出現(xiàn)了不正常、不正確、不按規(guī)范執(zhí)行的狀態(tài)，稱為軟件出錯。 63 ? 故障是物理地或靜態(tài)地存在的 ? 失誤、錯誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象 ? 軟件發(fā)生失效標志著軟件一次使用壽命的結(jié)束 ? 發(fā)生過失效的軟件通常仍然是可用的。無論是什么軟件，如果不對它的使用環(huán)境加以限制，都是會失效的。 67 ? 規(guī)定的功能 ─在考慮軟件可靠性時，首先應當明確 軟件的功能是什么 ， 哪些功能是主要的 ， 哪些功能是次要的 。此外，還要明確， 怎樣才算是完成了一個規(guī)定的功能 。設 測試用例發(fā)現(xiàn)植入故障和原有故障的能力相同 ，則 程序中原有故障總數(shù) N ( =ET )估算值為 NNnnss?78 Hyman分別測試法 ? 由兩個測試員同時互相獨立地測試同一程序的兩個副本，用 t 表示 測試時間 ，記 t＝ 0時， 程序中原有故障總數(shù)是 B0；t＝ t1 時， 測試員甲發(fā)現(xiàn)的故障總數(shù)是 B1； 測試員乙發(fā)現(xiàn)的故障總數(shù)是 B2；其中兩人發(fā)現(xiàn)的 相同故障數(shù)目是 bc；兩人發(fā)現(xiàn)的 不同故障數(shù)目是 bi。 B B Bbc01 2? ?80 測試精確度和測試覆蓋度的評價 ? 在軟件測試過程中累積發(fā)現(xiàn)的故障數(shù)，可用帶有平均值函數(shù) m(t) 的非齊次泊松過程 (NHPP)來描述： ? 其中， N是在測試中可能發(fā)現(xiàn)的故障總數(shù)， b是故障發(fā)現(xiàn)率。需要從測試的 量的方面 和 質(zhì)的方面 ，全面地評價測試。 ? 測定 Ac，需要預先植入播種故障，然后通過測試，根據(jù)播種故障的捕捉率來推測原有故障的捕獲率。 89 ? 測試過程中 已發(fā)現(xiàn)原有故障總數(shù) 為 n0(實測值 )，經(jīng)過相當長時間測試后 可能發(fā)現(xiàn)的原有故障總數(shù) 為 N0， ? 采用平均值函數(shù) m(t)的 NHPP模型 描述測試發(fā)現(xiàn)原有故障的過程 ? m(t)的收斂值 m(?)＝ Nc ? 測試覆蓋率 Cv的推測值 ： Cv =nNnmnNc000 0???( )90 ? 測試開始后，由于測試員對程序和測試環(huán)境不熟悉，造成拖期。 實測結(jié)果多是如 (B)所示的 S型曲線 。 ? 配置管理是一組標識、組織和控制修改的活動，目的是使錯誤達到最小并最有效地提高生產(chǎn)率。 ? 軟件配置是軟件的具體形態(tài)在某一時刻的瞬時影像。 97 基線 (Baseline) ? 基線是軟件生存期中各開發(fā)階段末尾的特定點，又稱里程碑。 ? 當軟件組織成員想要 對基線 SCI進行修改時 ， 把它從項目數(shù)據(jù)庫中復制到該工程師的專用工作區(qū)中 。來更新 B。 ? 系統(tǒng)規(guī)格說明 ? 軟件項目實施計劃 ? 軟件需求說明 ? 可執(zhí)行的原型 ? 初步的用戶手冊 ? 設計規(guī)格說明 103 ? 源代碼清單 ? 測試計劃和過程、測試用例和測試結(jié)果記錄 ? 操作和安裝手冊 ? 可執(zhí)行程序（可執(zhí)行程序模塊、連接模塊） ? 數(shù)據(jù)庫描述（模式和文件結(jié)構(gòu)、初始內(nèi)容） ? 正式的用戶手冊 ? 維護文檔（軟件問題報告、維護請求、工程變更次序） 104 ? 軟件工程標準 ? 項目開發(fā)總結(jié) ? 除以上所列 SCI以外，許多軟件工程組織還把 配置控制之下的軟件工具 列入其中，即 編輯程序 、 編譯程序 、 其它CASE工具的特定版本 。 ? 每個對象與其它對象的聯(lián)系用箭頭表示。 108 軟件配置管理的任務 ? 軟件配置管理（ SCM）的任務是： ? 標識單個的 SCI ? 標識和管理軟件各種版本 ? 控制變更 ? 審查軟件配置 ? 報告所有加在配置上的變更。 110 對象類型 ? 基本對象 ： 是由軟件工程師在分析、設計、編碼和測試時所建立的 文本單元 。 ? 對象 描述 包括： SCI類型 （如文檔、程序、數(shù)據(jù)）、 項目標識 、 變更 和／或 版本信息 。 ER diagram is part of data model。這些交叉的結(jié)構(gòu)聯(lián)系表達方式如下： data model interrelated data flow model。 ? 對于每一配置對象都可以建立一個演變圖 ，用演變圖記敘對象的 變更歷史 。 ? 版本控制管理在軟件工程過程中建立起配置對象的不同版本 。 118 119 ? 圖中的各個結(jié)點都是 聚合對象 ，是一個完全的軟件版本 。因此，可以定義版本的兩個變種。 ? 任何版本都可以隨時檢出編輯，同一應用的不同版本可以像樹枝一樣向上增長。 125 ? 在文件登入和檢出時，需要注意登入和檢出的使用 : ? 當需要修改某個小缺陷時，應 只檢出完成工作必需的最少文件 ； ? 需要對文件變更時，應登入它并加鎖 ， 保留對每個變更的記錄 ； ? 應避免長時間地鎖定文件。 ? 軟件工程過程中 某一階段的變更 ，均要引起軟件配置的變更 ，這種變更必須嚴格加以 控制 和 管理 ，保持修改信息。但是，如果發(fā)現(xiàn)錯誤的階段在造成錯誤的階段的后面，例如在實現(xiàn)階段發(fā)現(xiàn)了設計錯誤，則必須遵照標準的變更控制過程，把這個變更正式記入文檔，把所有受這個變更影響的文檔都做相應的修改。 134 ? 如果變更的代價比較高，或者影響比較大，則必須權(quán)衡利弊，以決定是否進行這種變更。 ? 在一個 SCI成為基線之前，可以對所有合理的項目和技術申請進行非正式的變更； ? 一旦某個 SCI經(jīng)過正式的技術評審并得到批準，它就成了基線。 ? 登錄主要 根據(jù)變更控制小組會議的記錄 ，并產(chǎn)生 配置狀態(tài)報告 。此外在軟件配置報告中新登錄的變更應當及時通知給管理人員和軟件工程師。 ? 軟件配置審計的目的就是要 ? 證實整個軟件生存期中各項產(chǎn)品在技術上和管理上的完整性。 ? 軟件的變更控制機制通常只能跟蹤到工程變更順序產(chǎn)生為止。 。 ? 正式技術評審應對所有的變更進行，除了那些最無價值的變更之外。使得軟件配置具有良好的可跟蹤性。避免了可能出現(xiàn)的不一致和沖突。 ? 一旦進行了配置審計，其結(jié)果也應該寫入報告之中。 136 配置狀態(tài)報告 ? 為了清楚、及時地記載軟件配置的變化，需要 對開發(fā)的過程做出系統(tǒng)的記錄 ，以反映開發(fā)活動的歷史情況。 如果是用戶要求的變更，則用戶應支付這筆費用；否則，必須完成某種成本／效益分析，以確定是否值得做這種變更。這類變更必須經(jīng)過某種正式的變更評價過程，以估計變更需要的成本和它對軟件系統(tǒng)其它部分的影響。 128 變更控制