【文章內(nèi)容簡介】 工件的保護是通過歸檔 、 建立基線和報告等操作而得以實現(xiàn)的 。 使用標準的 、 已記錄下來的 變更控制流程 的目的是：確保項目中所做的變更保持一致 ， 并將產(chǎn)品的狀態(tài) 、 對其所做的變更以及這些變更所耗費的成本及對時間表的影響通知給有關(guān)的涉眾 。 軟件配置管理計劃 說明在產(chǎn)品 /項目生命周期中要執(zhí)行的所有與配置管理相關(guān)的活動 。 它記錄如何計劃 、 實施 、 控制和組織與產(chǎn)品相關(guān)的配置管理活動 。 3/27/2023 43 配備人員 配置管理人員的選擇和配備 ， 是軟件項目經(jīng)理最主要的工作 。 在一個比較理想的軟件開發(fā)團隊中 ， 需要哪些角色呢 ？ 負責軟件項目組的項目經(jīng)理 負責 SCM計劃和策略的配置經(jīng)理 負責軟件產(chǎn)品開發(fā)與維護的軟件工程人員 負責驗證產(chǎn)品正確性的測試人員 負責確保產(chǎn)品高質(zhì)量的質(zhì)量保證經(jīng)理 使用產(chǎn)品的用戶 。 3/27/2023 44 配置經(jīng)理 配置經(jīng)理 的目標是確保用來建立 、 變更及編碼測試的計劃和策略得以貫徹執(zhí)行 ， 同時使有關(guān)項目的信息容易獲得 。 為了對編碼更改形成控制 ， 配置經(jīng)理引入規(guī)范的請求變更的機制 ， 評估更改的機制 （ 通過變更控制機構(gòu) CCB， 由它負責批準對軟件系統(tǒng)的變更 ） ， 和批準變更的機制 。 配置經(jīng)理負責為工程人員創(chuàng)建任務(wù)單 ， 交由項目經(jīng)理對任務(wù)進行分配 ， 創(chuàng)建項目的框架 。 同時 ， 配置經(jīng)理還收集軟件系統(tǒng)中構(gòu)件的相關(guān)數(shù)據(jù) ， 比如說用以判斷系統(tǒng)中出現(xiàn)問題的構(gòu)件的信息 。 3/27/2023 45 軟件配置及其管理的概念 配置管理活動和流程 配置管理需求 版本管理 變更管理 配置狀態(tài)監(jiān)測與報告 基于配置管理的軟件項目管理 配置管理的技術(shù)手段和工具 第八章 ? 目錄 3/27/2023 46 配置管理的對象 最基本的配置管理項 —— 文檔 UCM目錄結(jié)構(gòu)下的配置管理對象 配置管理需求 3/27/2023 47 配置管理對象 ? 配置管理的第一個基本活動是配置標識 ， 通俗地講 ， 也就是查詢 、 識別和確定配置管理對象 —— 配置項 。 在生產(chǎn)的軟件產(chǎn)品和軟件的生產(chǎn)過程中 ， 那些是配置管理的對象呢 ？ ? 配置管理對象呈現(xiàn)為一種層次結(jié)構(gòu) ， 因此 ， 為了標識配置管理的對象 ，我們需要對軟件系統(tǒng)進行分解： 目前 ， 用于分解軟件系統(tǒng)的術(shù)語有多種多樣 ， 沒有被標準化 。 ? 1989年 Humphery定義了 5個層次：系統(tǒng) 、 子系統(tǒng) 、 產(chǎn)品 、 構(gòu)件和模塊 。 ? 1991年 Whitgift定義了 3個層次：系統(tǒng) 、 子系統(tǒng)和元素 。 ? IEEE定義了 3個層次：計算機配置項 、 計算機軟件構(gòu)件和計算機軟件單元 。 ? RUP定義了 4個層次：系統(tǒng) 、 實施 （ 或構(gòu)件 ） 子系統(tǒng) 、 構(gòu)件和文件（ 1999） 。 3/27/2023 48 配置管理對象 ? 在 RUP的概念里 ， 最底層的元素是處于版本控制下的文件和目錄 ， 構(gòu)件的層次要高于元素（ 文件和目錄 ） ， 構(gòu)件把元素組織起來 。 一個版本控制的構(gòu)件是一個具體的物理的對象 ，就是一個根目錄 。 這個根目錄 ，以及從根目錄下所屬的所有目錄和文件 ， 是系統(tǒng)的一個子系統(tǒng) 。 大的系統(tǒng)有多個根目錄（ 子系統(tǒng) ） ， 小系統(tǒng)則可能只有一個根目錄 。 ?產(chǎn)品目錄結(jié)構(gòu)為所有可具有版本號的、與產(chǎn)品相關(guān)的工件提供邏輯嵌套的占位符。工件是開發(fā)流程生命周期的結(jié)果，用于開發(fā)整個系統(tǒng)的各組成部分（構(gòu)件）。 3/27/2023 49 配置管理對象 ? 首先我們從根目錄開始 （ 假設(shè)是只有一個根目錄的小 ） 系統(tǒng) ， 討論軟件系統(tǒng)架構(gòu)：軟件項目通過一系列的生命階段 ， 將建立或者已經(jīng)建立起一個體系構(gòu)架 。 軟件的體系構(gòu)架在軟件工程時代被稱為系統(tǒng)結(jié)構(gòu) 。 在 UML中 ， 被稱為構(gòu)架 。 ? UML對構(gòu)架的定義是： （ 1） 一組有關(guān)軟件系統(tǒng)組織結(jié)構(gòu)的重要決定； （ 2） 結(jié)構(gòu)要素和接口的選取 ， 確保它們的行為能滿足這些要素之間的協(xié)作關(guān)系； （ 3） 結(jié)構(gòu)要素和行為要素以一種漸進的方式被組裝成子系統(tǒng) ， 能夠指導這種組織結(jié)構(gòu)的結(jié)構(gòu)風格 ， 要素的內(nèi)容 ， 它們的接口 、 它們的協(xié)作和它們的組合 。 ? 系統(tǒng)或系統(tǒng)構(gòu)架是由子系統(tǒng) （ 構(gòu)件 ） 組成的 。 3/27/2023 50 ? UML進一步把構(gòu)件劃分成三種構(gòu)件：部署型構(gòu)件 、 工作產(chǎn)品型構(gòu)件和執(zhí)行構(gòu)件 。 （ 1） 部署型構(gòu)件：是指那些被部署到目標機中的元素 ， 例如：可執(zhí)行程序 、 庫以及其他支持系統(tǒng)運行的文件 。 （ 2） 工作型構(gòu)件：是構(gòu)成開發(fā)環(huán)境的元素 ， 例如：源文件 、 頭文件以及其他用于導出或構(gòu)建部署型構(gòu)件的文件 。 （ 3） 可執(zhí)行型構(gòu)件：是指由運行于目標機的系統(tǒng)生成的內(nèi)容 ， 例如：數(shù)據(jù)等 。 ? 從 SCM的角度看系統(tǒng)架構(gòu) ， 我們主要關(guān)注的是在開發(fā)環(huán)境中以及將來部署到目標系統(tǒng)中的系統(tǒng)的物理層面的文件和目錄結(jié)構(gòu) 、 分組和版本化 。 這種關(guān)注決定了配置管理的對象以及對象的 “ 粒度 ” 。 ? 現(xiàn)在 ， 有些項目使用高層次的設(shè)計文檔來描述架構(gòu) ， 例如：模型 、視圖等 。 在高層架構(gòu)描述中 ， 邏輯上的 “ 類 ” ， 可影射對應(yīng)為物理層面的文件和目錄 。 ? 作為軟件產(chǎn)品和軟件過程 ， 這些文件和目錄是 SCM控制的對象 ， 即他們是配置項 。 在我們現(xiàn)在的討論中 ， 有時 ， 我們說明這些文件是用于管理和設(shè)計系統(tǒng)的內(nèi)容 （ 包括：項目計劃 、 設(shè)計模型 、 測試報告 ）等 ， 有些是實現(xiàn)系統(tǒng)設(shè)計的文件 （ 包括：源代碼 、 庫 、 執(zhí)行文件等 ） ， 有時 ， 把它們不加區(qū)別地看成為構(gòu)件 。 3/27/2023 51 CMM2的配置管理對象 ? CMM2把配置管理對象 ， 稱之為軟件工作產(chǎn)品 ， 在 CMM2配置管理定義中 ， 對應(yīng)置于配置管理下的軟件工作產(chǎn)品 ， 是這樣定義的： ? 可作為配置項 /單元標識的軟件工作產(chǎn)品實例有： 與過程相關(guān)的文檔 （ 例如：計劃 、 標準或規(guī)程 ） 軟件需求 軟件設(shè)計 軟件代碼單元 軟件測試規(guī)程 為軟件測試活動建立的軟件系統(tǒng) 交付給客戶或最終用戶的軟件系統(tǒng) 編譯程序 其他支持工具 不論各體系是如何定義的 ， 我們基本可以認為 ， 配置管理的對象 ，主要地可以分為二類：軟件產(chǎn)品和文檔 。 軟件產(chǎn)品比較容易標識 ，而文檔相對比較復雜 。 我們將重點進行討論 。 ? 3/27/2023 52 最基本的配置管理項 —— 文檔 ? 文檔在軟件開發(fā)人員 、 軟件管理人員 、 維護人員 、 用戶以及計算機之間 ， 起到了多種的橋梁作用 。 軟件開發(fā)人員在軟件生命的各個階段中 ，以文檔作為前階段工作成果的體現(xiàn)和后階段工作的依據(jù) ， 這個作用是顯而易見的 。 這部分文檔通常稱為開發(fā)文檔 。 ? 軟件開發(fā)過程中軟件開發(fā)人員需制定一些工作計劃或工作報告 ， 這些計劃和報告都要提供給管理人員 ， 并得到必要的支持 。 管理人員則可通過這些文檔了解軟件開發(fā)項目安排 、 進度 、 資源使用和成果等 。這部分文檔通常稱為管理文檔 ， 或稱為項目文檔 。 ? 軟件開發(fā)人員需為用戶了解軟件的使用 、 操作和維護提供詳細的資料 。這部分文檔通常稱為用戶文檔 。 3/27/2023 53 我們把這三種文檔所包括的內(nèi)容列在下圖中。其中列舉了十三個文檔，這里對它們做一些簡要說明： 文檔 用戶文檔 用戶手冊 操作手冊 維護修改建議 軟件需求 （ 規(guī)格 ） 說明書 開發(fā)文檔 軟件需求 （ 規(guī)格 ） 說明書 數(shù)據(jù)要求說明書 概要設(shè)計說明書 詳細設(shè)計說明書 可行性研究報告 項目開發(fā)計劃 管理文檔 項目開發(fā)計劃 測試計劃 測試報告 開發(fā)進度月報 開發(fā)總結(jié)報告 3/27/2023 54 文檔的生成階段 階段 文檔 可行性研究與計劃 需求分析 設(shè)計 代碼編寫 測試 運行與維護 可行性研究報告 項目開發(fā)計劃 軟件需求說明 數(shù)據(jù)要求說明 概要設(shè)計說明 詳細設(shè)計說明 測試計劃 用戶手冊 操作手冊 測試分析報告 開發(fā)進度月報 項目開發(fā)總結(jié) 維護修改建議 3/27/2023 55 文檔的作用 所提問題 文檔 什么 何處 何時 誰 如何 為何 可行性研究報告 √ √ 項目開發(fā)計劃 √ √ √ 軟件需求說明 √ √ 數(shù)據(jù)要求說明 √ √ 概要設(shè)計說明 √ 詳細設(shè)計說明 √ 測試計劃 √ √ √ 用戶手冊 √ 操作手冊 √ 測試分析報告 √ 開發(fā)進度月報 √ √ 項目開發(fā)總結(jié) √ 維護修改建議 √ √ √ 3/27/2023 56 UCM目錄結(jié)構(gòu)下的配置管理 UCM（ 統(tǒng)一變更管理 ） 的發(fā)展沿革 第一代 UCM： 第二代 UCM： 第三代 UCM： ? 第三代 UCM引進了一些新的概念： （ 1） 活動 （ Activity） ： （ 2） 構(gòu)件 （ Component） ： （ 3） 工作流 （ Stream） ： （ 4） 項目 （ Project） ： 3/27/2023 57 軟件配置及其管理的概念 配置管理活動和流程 配置管理需求 版本管理 變更管理 配置狀態(tài)監(jiān)測與報告 基于配置管理的軟件項目管理 配置管理的技術(shù)手段和工具 第八章 ? 目錄 3/27/2023 58 版本管理的必要性 此前的版本管理 元素、分支與版本 構(gòu)件、基線與存儲池 現(xiàn)代版本管理活動 版本管理 3/27/2023 59 版本管理的必要性 在軟件開發(fā)過程中 ， 由于軟件開發(fā)所固有的特征 ， 可能會形成眾多的軟件版本 ， 而且我們并不能保證不出現(xiàn)錯誤的修改 ， 而這樣的一個困難局面卻又非?，F(xiàn)實地擺在項目開發(fā)管理者的面前 ， 他 /她該如何有效地解決這些問題 ， 具體地說就是如下一些問題： （ 1） 怎樣對研發(fā)項目進行整體管理； （ 2） 項目開發(fā)小組的成員之間如何以一種有效的機制進行協(xié)調(diào)； （ 3） 如何進行對小組成員各自承擔的子項目的統(tǒng)一管理； （ 4） 如何對研發(fā)小組各成員所作的修改進行統(tǒng)一匯總； （ 5） 如何保留修改的軌跡 ， 以便撤銷錯誤的改動； （ 6） 對在研發(fā)過程中形成的軟件的各個版本如何進行標識 ， 管理及差異識辨等等 。 一個非常直接的反應(yīng)是 ， 我們必須要引進一種管理機制 ， 一個版本管理機制 ， 而且是廣義上的版本管理 ， 它不僅需要對源代碼的版本進行管理 ， 而且還要對整個項目進行管理 。 3/27/2023 60 ? 在軟件工程時代 ， 面對這樣的問題 ， 我們通過以往的那種被譽建立具有良好的編程風格的做法 ， 諸如在編程或?qū)λ说脑闯绦蜻M行修改時 ， 注釋修改原因 ， 修改人和日期 。 如果是多個成員同時進行了修改 ， 那么可能出現(xiàn)一個庫管理員 ， 由他來控制什么人在訪問哪個源代碼 ， 修改的人向他報告做了什么改動 。 如果有幾個人同時改動 ， 庫管理員或者限定同時只能有一個