【正文】 。 ? 正式技術(shù)評(píng)審應(yīng)對(duì)所有的變更進(jìn)行，除了那些最無價(jià)值的變更之外。 ? 軟件的變更控制機(jī)制通常只能跟蹤到工程變更順序產(chǎn)生為止。使得軟件配置具有良好的可跟蹤性。 ? 軟件配置審計(jì)的目的就是要 ? 證實(shí)整個(gè)軟件生存期中各項(xiàng)產(chǎn)品在技術(shù)上和管理上的完整性。避免了可能出現(xiàn)的不一致和沖突。此外在軟件配置報(bào)告中新登錄的變更應(yīng)當(dāng)及時(shí)通知給管理人員和軟件工程師。 ? 一旦進(jìn)行了配置審計(jì)，其結(jié)果也應(yīng)該寫入報(bào)告之中。 ? 登錄主要 根據(jù)變更控制小組會(huì)議的記錄 ，并產(chǎn)生 配置狀態(tài)報(bào)告 。 136 配置狀態(tài)報(bào)告 ? 為了清楚、及時(shí)地記載軟件配置的變化，需要 對(duì)開發(fā)的過程做出系統(tǒng)的記錄 ，以反映開發(fā)活動(dòng)的歷史情況。 ? 在一個(gè) SCI成為基線之前，可以對(duì)所有合理的項(xiàng)目和技術(shù)申請(qǐng)進(jìn)行非正式的變更； ? 一旦某個(gè) SCI經(jīng)過正式的技術(shù)評(píng)審并得到批準(zhǔn)，它就成了基線。 如果是用戶要求的變更，則用戶應(yīng)支付這筆費(fèi)用；否則，必須完成某種成本／效益分析，以確定是否值得做這種變更。 134 ? 如果變更的代價(jià)比較高，或者影響比較大，則必須權(quán)衡利弊，以決定是否進(jìn)行這種變更。這類變更必須經(jīng)過某種正式的變更評(píng)價(jià)過程，以估計(jì)變更需要的成本和它對(duì)軟件系統(tǒng)其它部分的影響。但是，如果發(fā)現(xiàn)錯(cuò)誤的階段在造成錯(cuò)誤的階段的后面，例如在實(shí)現(xiàn)階段發(fā)現(xiàn)了設(shè)計(jì)錯(cuò)誤，則必須遵照標(biāo)準(zhǔn)的變更控制過程，把這個(gè)變更正式記入文檔，把所有受這個(gè)變更影響的文檔都做相應(yīng)的修改。 128 變更控制 過程 129 132 軟件變更有兩類不同情況： ? 為改正小錯(cuò)誤需要的變更 。 ? 軟件工程過程中 某一階段的變更 ，均要引起軟件配置的變更 ，這種變更必須嚴(yán)格加以 控制 和 管理 ，保持修改信息。 126 ? 如果需要做較大的變更，可有兩種選擇： ，然后正常處理 ； ，把變更與主干“ 脫機(jī) ”，然后把結(jié)果合并回去。 125 ? 在文件登入和檢出時(shí)，需要注意登入和檢出的使用 : ? 當(dāng)需要修改某個(gè)小缺陷時(shí)，應(yīng) 只檢出完成工作必需的最少文件 ； ? 需要對(duì)文件變更時(shí)，應(yīng)登入它并加鎖 ， 保留對(duì)每個(gè)變更的記錄 ； ? 應(yīng)避免長時(shí)間地鎖定文件。 ? 某一文件一旦被 登入 ， 鎖即被解除 ，該文件可被其它用戶使用。 ? 任何版本都可以隨時(shí)檢出編輯，同一應(yīng)用的不同版本可以像樹枝一樣向上增長。 ? 用戶通過登入（ check in）和檢出（ check out）的方式訪問服務(wù)器上的文件，未經(jīng)授權(quán)的用戶無法訪問服務(wù)器上的文件。因此，可以定義版本的兩個(gè)變種。 ? 例如，一個(gè)簡單的程序版本由 4和 5等部件組成。 118 119 ? 圖中的各個(gè)結(jié)點(diǎn)都是 聚合對(duì)象 ，是一個(gè)完全的軟件版本 。 ? 通過 描述所希望的屬性集合 來 確定 （或構(gòu)造 ） 所想要的配置 。 ? 版本控制管理在軟件工程過程中建立起配置對(duì)象的不同版本 。 ? 為了得到較早時(shí)期 (文檔或程序 )的版本，可以從最后版本中 “提取”出 (由工具編目的 )變更 ，使得 當(dāng)前配置直接可用 ，并使得 其它版本也可用 。 ? 對(duì)于每一配置對(duì)象都可以建立一個(gè)演變圖 ，用演變圖記敘對(duì)象的 變更歷史 。 (一個(gè)復(fù)合對(duì)象與一個(gè)特定的基本對(duì)象之間的相互聯(lián)系） 114 演變圖 ? 整個(gè)軟件工程過程中所涉及的軟件對(duì)象都必須加以標(biāo)識(shí)。這些交叉的結(jié)構(gòu)聯(lián)系表達(dá)方式如下： data model interrelated data flow model。 ? 就可以建立 SCI的一個(gè)層次。 ER diagram is part of data model。 ? 基本對(duì)象的實(shí)現(xiàn) 是 指向 文本單元 的指針 ，復(fù)合對(duì)象的實(shí)現(xiàn)為 null。 ? 對(duì)象 描述 包括： SCI類型 （如文檔、程序、數(shù)據(jù)）、 項(xiàng)目標(biāo)識(shí) 、 變更 和／或 版本信息 。 ? 復(fù)合對(duì)象 ： 是基本對(duì)象或其它復(fù)合對(duì)象的 一個(gè)收集 。 110 對(duì)象類型 ? 基本對(duì)象 ： 是由軟件工程師在分析、設(shè)計(jì)、編碼和測試時(shí)所建立的 文本單元 。 ? 整個(gè)軟件生存期的 軟件配置就象一部不斷演變的電影 ，而某一時(shí)刻的配置就是這部電影的一個(gè)片段。 108 軟件配置管理的任務(wù) ? 軟件配置管理（ SCM）的任務(wù)是： ? 標(biāo)識(shí)單個(gè)的 SCI ? 標(biāo)識(shí)和管理軟件各種版本 ? 控制變更 ? 審查軟件配置 ? 報(bào)告所有加在配置上的變更。 106 配置對(duì)象 107 ? 雙向箭頭則表明一種相互關(guān)系 。 ? 每個(gè)對(duì)象與其它對(duì)象的聯(lián)系用箭頭表示。 105 配置對(duì)象 ? 在實(shí)現(xiàn) SCM時(shí)，把 SCI組織成配置對(duì)象 ，在項(xiàng)目數(shù)據(jù)庫中用一個(gè) 單一的名字來組織它們 。 ? 系統(tǒng)規(guī)格說明 ? 軟件項(xiàng)目實(shí)施計(jì)劃 ? 軟件需求說明 ? 可執(zhí)行的原型 ? 初步的用戶手冊 ? 設(shè)計(jì)規(guī)格說明 103 ? 源代碼清單 ? 測試計(jì)劃和過程、測試用例和測試結(jié)果記錄 ? 操作和安裝手冊 ? 可執(zhí)行程序（可執(zhí)行程序模塊、連接模塊） ? 數(shù)據(jù)庫描述（模式和文件結(jié)構(gòu)、初始內(nèi)容） ? 正式的用戶手冊 ? 維護(hù)文檔（軟件問題報(bào)告、維護(hù)請(qǐng)求、工程變更次序） 104 ? 軟件工程標(biāo)準(zhǔn) ? 項(xiàng)目開發(fā)總結(jié) ? 除以上所列 SCI以外，許多軟件工程組織還把 配置控制之下的軟件工具 列入其中，即 編輯程序 、 編譯程序 、 其它CASE工具的特定版本 。 ? 在變更完成、評(píng)審和批準(zhǔn)之前，不許對(duì)它做任何操作。來更新 B。 工程師在 B39。 ? 當(dāng)軟件組織成員想要 對(duì)基線 SCI進(jìn)行修改時(shí) ， 把它從項(xiàng)目數(shù)據(jù)庫中復(fù)制到該工程師的專用工作區(qū)中 。 ? 基線的 作用是把各階段工作的劃分更加明確化 ，以便于檢驗(yàn)和肯定階段成果。 97 基線 (Baseline) ? 基線是軟件生存期中各開發(fā)階段末尾的特定點(diǎn)，又稱里程碑。系統(tǒng)規(guī)格說明可繁衍出軟件項(xiàng)目實(shí)施計(jì)劃和軟件需求規(guī)格說明。 ? 軟件配置是軟件的具體形態(tài)在某一時(shí)刻的瞬時(shí)影像。 ? SCM活動(dòng)的目標(biāo)是為了 (1) 標(biāo)識(shí)變更； (2) 控制變更； (3) 確保變更正確地實(shí)現(xiàn)； (4) 向其他有關(guān)的人報(bào)告變更。 ? 配置管理是一組標(biāo)識(shí)、組織和控制修改的活動(dòng)，目的是使錯(cuò)誤達(dá)到最小并最有效地提高生產(chǎn)率。 94 軟件配置管理 ? 在軟件建立時(shí) 變更是不可避免的 ，因?yàn)樵谶M(jìn)行變更前沒有仔細(xì)分析，或沒有進(jìn)行變更控制， 變更加劇了項(xiàng)目中軟件人員之間的混亂 。 實(shí)測結(jié)果多是如 (B)所示的 S型曲線 。 m t N e b t d( ) ( )( )? ? ? ?191 92 ? 測試員從發(fā)現(xiàn)錯(cuò)誤征兆到確認(rèn)錯(cuò)誤，需要反復(fù)執(zhí)行程序，以再現(xiàn)錯(cuò)誤，造成時(shí)間拖延。 89 ? 測試過程中 已發(fā)現(xiàn)原有故障總數(shù) 為 n0(實(shí)測值 )，經(jīng)過相當(dāng)長時(shí)間測試后 可能發(fā)現(xiàn)的原有故障總數(shù) 為 N0， ? 采用平均值函數(shù) m(t)的 NHPP模型 描述測試發(fā)現(xiàn)原有故障的過程 ? m(t)的收斂值 m(?)＝ Nc ? 測試覆蓋率 Cv的推測值 ： Cv =nNnmnNc000 0???( )90 ? 測試開始后，由于測試員對(duì)程序和測試環(huán)境不熟悉，造成拖期。 y N e i ni bt i? ? ??( ), , ,1 0 ?88 測試覆蓋率 Cv ? 表明在整個(gè)測試期間發(fā)現(xiàn)軟件內(nèi)潛在故障的可能性有多大。 ? 測定 Ac，需要預(yù)先植入播種故障，然后通過測試，根據(jù)播種故障的捕捉率來推測原有故障的捕獲率。 測試結(jié)束時(shí)軟件產(chǎn)品質(zhì)量水準(zhǔn) 84 ? 測試質(zhì)量的度量可以靠 測試的故障捕捉率和遺漏率 來衡量