【正文】 信息 。 ? 資源 包括由對象 產(chǎn)生的 、 處理的 、 引用的 或 其它需要 的 一些實體 。 ? 基本對象的實現(xiàn) 是 指向 文本單元 的指針 ，復(fù)合對象的實現(xiàn)為 null。 112 命名對象之間的聯(lián)系 ? 對象的層次關(guān)系： 一個對象可以是一個復(fù)合對象的一個組成部分，用聯(lián)系 is part of 標(biāo)識 。 ER diagram is part of data model。 data model is part of Design Specification。 ? 就可以建立 SCI的一個層次。 113 ? 對象的相互關(guān)聯(lián)關(guān)系： 對象跨越對象層次的分支相互關(guān)聯(lián)。這些交叉的結(jié)構(gòu)聯(lián)系表達(dá)方式如下： data model interrelated data flow model。 (兩個復(fù)合對象之間的相互聯(lián)系 ) data model interrelated test case class m。 (一個復(fù)合對象與一個特定的基本對象之間的相互聯(lián)系） 114 演變圖 ? 整個軟件工程過程中所涉及的軟件對象都必須加以標(biāo)識。 ? 在對象成為基線以前可能要做多次變更，在成為基線之后也可能需要頻繁地變更。 ? 對于每一配置對象都可以建立一個演變圖 ，用演變圖記敘對象的 變更歷史 。 115 演變圖 116 ? 在某些工具中，當(dāng)前保持的 只是最后版本的完全副本 。 ? 為了得到較早時期 (文檔或程序 )的版本，可以從最后版本中 “提取”出 (由工具編目的 )變更 ，使得 當(dāng)前配置直接可用 ，并使得 其它版本也可用 。 117 版本控制 ? 版本控制是 SCM的基礎(chǔ)，它管理并保護(hù)開發(fā)者的軟件資源。 ? 版本控制管理在軟件工程過程中建立起配置對象的不同版本 。 ? 版本管理可以把 一些屬性結(jié)合到各個軟件版本 上。 ? 通過 描述所希望的屬性集合 來 確定 （或構(gòu)造 ） 所想要的配置 。 ? 使用演變圖來表示系統(tǒng)的不同版本。 118 119 ? 圖中的各個結(jié)點都是 聚合對象 ，是一個完全的軟件版本 。 ? 軟件的每一版本都是 SCI（源代碼、文檔、數(shù)據(jù)） 的一個收集 ，且各個版本都可能由不同的變種組成。 ? 例如，一個簡單的程序版本由 4和 5等部件組成。其中 部件 4在軟件 使用彩色顯示器 時使用， 部件 5在軟件 使用單色顯示器 時使用。因此，可以定義版本的兩個變種。 120 版本管理的主要任務(wù) ? 集中管理檔案，安全授權(quán)機制 ： ? 版本管理的操作 將開發(fā)組的檔案集中地存放在服務(wù)器上 ， 經(jīng)系統(tǒng)管理員授權(quán)給各個用戶 。 ? 用戶通過登入（ check in）和檢出（ check out）的方式訪問服務(wù)器上的文件，未經(jīng)授權(quán)的用戶無法訪問服務(wù)器上的文件。 121 122 ? 軟件版本升級管理 ： ? 每次登入時，在服務(wù)器上都會生成新的版本。 ? 任何版本都可以隨時檢出編輯，同一應(yīng)用的不同版本可以像樹枝一樣向上增長。 123 124 ? 加鎖功能 ： ? 目的是 在文件更新時保護(hù)文件 ，避免不同用戶更改同一文件時發(fā)生沖突 。 ? 某一文件一旦被 登入 ， 鎖即被解除 ，該文件可被其它用戶使用。 ? 在 更新一個文件之前鎖定它 ，避免變更沒有鎖定的項目源文件。 125 ? 在文件登入和檢出時，需要注意登入和檢出的使用 : ? 當(dāng)需要修改某個小缺陷時，應(yīng) 只檢出完成工作必需的最少文件 ； ? 需要對文件變更時，應(yīng)登入它并加鎖 ， 保留對每個變更的記錄 ； ? 應(yīng)避免長時間地鎖定文件。如果需要長時間工作于某個文件，最好能 創(chuàng)建一個分支 ，并在分支上做工作。 126 ? 如果需要做較大的變更，可有兩種選擇： ，然后正常處理 ； ，把變更與主干“ 脫機 ”，然后把結(jié)果合并回去。 127 變更控制 ? 軟件生存期內(nèi)全部的軟件配置是軟件產(chǎn)品的真正代表 ，必須使其保持 精確 。 ? 軟件工程過程中 某一階段的變更 ，均要引起軟件配置的變更 ，這種變更必須嚴(yán)格加以 控制 和 管理 ，保持修改信息。 ? 變更控制包括 建立控制點 和 建立報告與審查制度 。 128 變更控制 過程 129 132 軟件變更有兩類不同情況： ? 為改正小錯誤需要的變更 。它是必須進(jìn)行的，通常不需要從管理角度對這類變更進(jìn)行審查和批準(zhǔn)。但是，如果發(fā)現(xiàn)錯誤的階段在造成錯誤的階段的后面，例如在實現(xiàn)階段發(fā)現(xiàn)了設(shè)計錯誤，則必須遵照標(biāo)準(zhǔn)的變更控制過程，把這個變更正式記入文檔，把所有受這個變更影響的文檔都做相應(yīng)的修改。 133 ? 為了增加或者刪掉某些功能、或者為了改變完成某個功能的方法而需要的變更 。這類變更必須經(jīng)過某種正式的變更評價過程，以估計變更需要的成本和它對軟件系統(tǒng)其它部分的影響。 ? 如果變更的代價比較小且對軟件系統(tǒng)其它部分沒有影響，或影響很小，通常應(yīng)批準(zhǔn)這個變更。 134 ? 如果變更的代價比較高，或者影響比較大，則必須權(quán)衡利弊，以決定是否進(jìn)行這種變更。 ? 如果同意這種變更， 需要進(jìn)一步確定由誰來支付變更所需要的費用。 如果是用戶要求的變更，則用戶應(yīng)支付這筆費用；否則，必須完成某種成本／效益分析，以確定是否值得做這種變更。 135 ? 這種變更報告和審查制度，對變更控制來說起了一個安全保證作用。 ? 在一個 SCI成為基線之前，可以對所有合理的項目和技術(shù)申請進(jìn)行非正式的變更； ? 一旦某個 SCI經(jīng)過正式的技術(shù)評審并得到批準(zhǔn)，它就成了基線。以后如果需要對它變更，就必須得到項目負(fù)責(zé)人的批準(zhǔn)，或者必須得到變更控制負(fù)責(zé)人的批準(zhǔn)。 136 配置狀態(tài)報告 ? 為了清楚、及時地記載軟件配置的變化，需要 對開發(fā)的過程做出系統(tǒng)的記錄 ，以反映開發(fā)活動的歷史情況。這就是配置狀態(tài)登錄的任務(wù)。 ? 登錄主要 根據(jù)變更控制小組會議的記錄 ，并產(chǎn)生 配置狀態(tài)報告 。 ? 對于每一項變更，記錄：發(fā)生了什么？為什么會發(fā)生？誰做的？什么時侯發(fā)生的？會有什么影響？ 137 配置狀態(tài)報告信息流 138 ? 每次 新分配一個 SCI，或 更新一個已有SCI的標(biāo)識 ，或 一項變更申請被變更控制負(fù)責(zé)人批準(zhǔn) ， 并給出了一個工程變更順序 時 ，在配置狀態(tài)報告中就要增加一條變更記錄條目。 ? 一旦進(jìn)行了配置審計，其結(jié)果也應(yīng)該寫入報告之中。 139 ? 配置狀態(tài)報告可以放在一個聯(lián)機數(shù)據(jù)庫中，以便軟件開發(fā)人員或者軟件維護(hù)人員可以對它進(jìn)行查詢或修改。此外在軟件配置報告中新登錄的變更應(yīng)當(dāng)及時通知給管理人員和軟件工程師。 ? 配置狀態(tài)報告對于大型軟件開發(fā)項目的成功起著至關(guān)重要的作用。避免了可能出現(xiàn)的不一致和沖突。 140 配置審計 ? 軟件的完整性 ，是指開發(fā)后期的 軟件產(chǎn)品能夠正確地反映用戶要求 。 ? 軟件配置審計的目的就是要 ? 證實整個軟件生存期中各項產(chǎn)品在技術(shù)上和管理上的完整性。 ? 確保所有文檔的內(nèi)容變動不超出當(dāng)初確定的軟件要求范圍。使得軟件配置具有良好的可跟蹤性。 141 ? 軟件配置審計是軟件變更控制人員 掌握配置情況 、 進(jìn)行審批的依據(jù) 。 ? 軟件的變更控制機制通常只能跟蹤到工程變更順序產(chǎn)生為止。為確認(rèn)變更是否正確完成 ? 一般可以用以下兩種方法去審查： ? 正式技術(shù)評審 ? 軟件配置審計 142 ? 正式的技術(shù)評審 著重 檢查已完成修改的軟件配置對象的技術(shù)正確性 ， ? 評審者 評價 SCI，決定它與其它 SCI的一致性，是否有遺漏或可能引起的副作用。 ? 正式技術(shù)評審應(yīng)對所有的變更進(jìn)行，除了那些最無價值的變更之外。 ? 軟件配置審計 作為正式技術(shù)評審的補充，評價在評審期間通常沒有被考慮的 SCI的特性 。