【正文】 基線庫的結(jié)構(gòu) (VOB) Project Root Directory Project Planning Phase Documents Requirements Analysis Phase Documents Design Phase Documents Code, Unit Test amp。 因此，配置管理從基礎(chǔ)層開始，有機地把其它支持活動結(jié)合起來，形成一個整體，相互促進，相互影響，有力地保證了質(zhì)量體系的實施。 2022/2/16 35 配置項 （ Software Configuration Item， SCI） 識別 對于配置項 ， 可以給出一個比較簡單的定義 ， 既軟件過程的輸出信息可以分為三個主要類別： （ 1） 計算機程序 （ 源代碼和可執(zhí)行程序 ） （ 2） 描述計算機程序的文檔 （ 針對技術(shù)開發(fā)者和用戶 ） （ 3） 數(shù)據(jù) （ 包含在程序內(nèi)部或外部 ） 。 2022/2/16 36 配置項 （ Software Configuration Item， SCI） 識別 軟件配置管理認為軟件的開發(fā)過程是一個不斷變化著的過程 ， 為了在不嚴重阻礙合理變化的情況下來控制變化 ， 軟件配置管理引入了“ 基線 （ Base Line） ” 這一概念 。 2022/2/16 37 配置項的標(biāo)識和控制 所有配置項都應(yīng)按照相關(guān)規(guī)定統(tǒng)一編號 ， 按照相應(yīng)的模板生成 ， 并在文檔中的規(guī)定章節(jié) （ 部分 ） 記錄對象的標(biāo)識信息 。 每個開發(fā)人員按照任務(wù)的要求 ， 在不同的開發(fā)階段 ， 工作在不同的工作空間上 。 版本在生成過程中 ， 自動依照設(shè)定的使用模型自動分支 、 演進 。 一般來說 ， 對于基線版本之前的各個版本都應(yīng)處于被鎖定的狀態(tài) ， 如需要對它們進行變更 ， 則應(yīng)按照變更控制的流程來進行操作 。 2022/2/16 42 配置審計 配置審計的主要作用是作為變更控制的補充手段 ， 來確保某一變更需求已被切實實現(xiàn) 。 因此 ， 軟件配置管理的主要任務(wù)也就歸結(jié)為以下幾條： （ 1） 制定項目的配置計劃； （ 2） 對配置項進行標(biāo)識； （ 3） 對配置項進行版本控制； （ 4） 對配置項進行變更控制； （ 5） 定期進行配置審計； （ 6） 向相關(guān)人員報告配置的狀態(tài) 。 使用標(biāo)準(zhǔn)的 、 已記錄下來的 變更控制流程 的目的是：確保項目中所做的變更保持一致 ， 并將產(chǎn)品的狀態(tài) 、 對其所做的變更以及這些變更所耗費的成本及對時間表的影響通知給有關(guān)的涉眾 。 在一個比較理想的軟件開發(fā)團隊中 ， 需要哪些角色呢 ？ 負責(zé)軟件項目組的項目經(jīng)理 負責(zé) SCM計劃和策略的配置經(jīng)理 負責(zé)軟件產(chǎn)品開發(fā)與維護的軟件工程人員 負責(zé)驗證產(chǎn)品正確性的測試人員 負責(zé)確保產(chǎn)品高質(zhì)量的質(zhì)量保證經(jīng)理 使用產(chǎn)品的用戶 。 同時 ， 配置經(jīng)理還收集軟件系統(tǒng)中構(gòu)件的相關(guān)數(shù)據(jù) ， 比如說用以判斷系統(tǒng)中出現(xiàn)問題的構(gòu)件的信息 。 ? 1991年 Whitgift定義了 3個層次：系統(tǒng) 、 子系統(tǒng)和元素 。 一個版本控制的構(gòu)件是一個具體的物理的對象 ，就是一個根目錄 。工件是開發(fā)流程生命周期的結(jié)果，用于開發(fā)整個系統(tǒng)的各組成部分（構(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) ， 能夠指導(dǎo)這種組織結(jié)構(gòu)的結(jié)構(gòu)風(fēng)格 ， 要素的內(nèi)容 ， 它們的接口 、 它們的協(xié)作和它們的組合 。 （ 2） 工作型構(gòu)件：是構(gòu)成開發(fā)環(huán)境的元素 ， 例如：源文件 、 頭文件以及其他用于導(dǎo)出或構(gòu)建部署型構(gòu)件的文件 。 ? 現(xiàn)在 ， 有些項目使用高層次的設(shè)計文檔來描述架構(gòu) ， 例如：模型 、 視圖等 。 2022/2/16 53 CMM2的配置管理對象 ? CMM2把配置管理對象 ， 稱之為軟件工作產(chǎn)品 ， 在 CMM2配置管理定義中 ，對應(yīng)置于配置管理下的軟件工作產(chǎn)品 ， 是這樣定義的： ? 可作為配置項 /單元標(biāo)識的軟件工作產(chǎn)品實例有： 與過程相關(guān)的文檔 （ 例如：計劃 、 標(biāo)準(zhǔn)或規(guī)程 ） 軟件需求 軟件設(shè)計 軟件代碼單元 軟件測試規(guī)程 為軟件測試活動建立的軟件系統(tǒng) 交付給客戶或最終用戶的軟件系統(tǒng) 編譯程序 其他支持工具 不論各體系是如何定義的 ， 我們基本可以認為 ， 配置管理的對象 ， 主要地可以分為二類：軟件產(chǎn)品和文檔 。 軟件開發(fā)人員在軟件生命的各個階段中 ，以文檔作為前階段工作成果的體現(xiàn)和后階段工作的依據(jù) ， 這個作用是顯而易見的 。這部分文檔通常稱為管理文檔 ， 或稱為項目文檔 。其中列舉了十三個文檔，這里對它們做一些簡要說明： 文檔 用戶文檔 用戶手冊 操作手冊 維護修改建議 軟件需求 （ 規(guī)格 ） 說明書 開發(fā)文檔 軟件需求 （ 規(guī)格 ） 說明書 數(shù)據(jù)要求說明書 概要設(shè)計說明書 詳細設(shè)計說明書 可行性研究報告 項目開發(fā)計劃 管理文檔 項目開發(fā)計劃 測試計劃 測試報告 開發(fā)進度月報 開發(fā)總結(jié)報告 2022/2/16 56 文檔的生成階段 階段 文檔 可行性研究與計劃 需求分析 設(shè)計 代碼編寫 測試 運行與維護 可行性研究報告 項目開發(fā)計劃 軟件需求說明 數(shù)據(jù)要求說明 概要設(shè)計說明 詳細設(shè)計說明 測試計劃 用戶手冊 操作手冊 測試分析報告 開發(fā)進度月報 項目開發(fā)總結(jié) 維護修改建議 2022/2/16 57 文檔的作用 所提問題 文檔 什么 何處 何時 誰 如何 為何 可行性研究報告 √ √ 項目開發(fā)計劃 √ √ √ 軟件需求說明 √ √ 數(shù)據(jù)要求說明 √ √ 概要設(shè)計說明 √ 詳細設(shè)計說明 √ 測試計劃 √ √ √ 用戶手冊 √ 操作手冊 √ 測試分析報告 √ 開發(fā)進度月報 √ √ 項目開發(fā)總結(jié) √ 維護修改建議 √ √ √ 2022/2/16 58 UCM目錄結(jié)構(gòu)下的配置管理 UCM（ 統(tǒng)一變更管理 ） 的發(fā)展沿革 第一代 UCM： 第二代 UCM： 第三代 UCM： ? 第三代 UCM引進了一些新的概念： （ 1） 活動 （ Activity） ： （ 2） 構(gòu)件 （ Component） ： （ 3） 工作流 （ Stream） ： （ 4） 項目 （ Project） ： 2022/2/16 59 軟件配置及其管理的概念 配置管理活動和流程 配置管理需求 版本管理 變更管理 配置狀態(tài)監(jiān)測與報告 基于配置管理的軟件項目管理 配置管理的技術(shù)手段和工具 配置管理 2022/2/16 60 版本管理的必要性 此前的版本管理 元素、分支與版本 構(gòu)件、基線與存儲池 現(xiàn)代版本管理活動 版本管理 2022/2/16 61 版本管理的必要性 在軟件開發(fā)過程中 ， 由于軟件開發(fā)所固有的特征 ， 可能會形成眾多的軟件版本 ， 而且我們并不能保證不出現(xiàn)錯誤的修改 ， 而這樣的一個困難局面卻又非?，F(xiàn)實地擺在項目開發(fā)管理者的面前 ， 他 /她該如何有效地解決這些問題 ， 具體地說就是如下一些問題： （ 1） 怎樣對研發(fā)項目進行整體管理； （ 2） 項目開發(fā)小組的成員之間如何以一種有效的機制進行協(xié)調(diào)； （ 3） 如何進行對小組成員各自承擔(dān)的子項目的統(tǒng)一管理； （ 4） 如何對研發(fā)小組各成員所作的修改進行統(tǒng)一匯總； （ 5） 如何保留修改的軌跡 ， 以便撤銷錯誤的改動； （ 6） 對在研發(fā)過程中形成的軟件的各個版本如何進行標(biāo)識 ， 管理及差異識辨等等 。 如果有幾個人同時改動 ， 庫管理員或者限定同時只能有一個人做修改 ， 他記住這人是誰 ， 或者他自己來做同時修改的人工的差異比較和綜合 ， 以便形成一個統(tǒng)一的新版本 。 他們是怎么做的 ？ 最簡單的辦法是使用文件拷貝支持不同的版本 。 ? 這些工具基本上能幫助庫管理員從手工的管理中解脫出來 ，開發(fā)人員不需要庫管理員的介入 ， 可以自己從庫中檢入和檢出文件 ， 當(dāng)文件被檢出后 ， 其他人暫時不能再檢出此文件 。 每個文件和項目的每個版本都有一個版本號 ， 這些版本號總是一個整數(shù)且是遞增的 。 2022/2/16 65 元素、分支與版本 原子對象 在 ClearCase的概念中 ， 置于版本控制下的原子對象被稱為 “ 元素 ” （ element） ， 元素是文件系統(tǒng)對象：文件和目錄 。 分支是線形的版本序列 ， 版本序列構(gòu)成的是并行開發(fā)的項目或基于統(tǒng)一基線開始的不同的系統(tǒng) 。 “ 發(fā)布版本”是這個版本上的標(biāo)簽 。 目錄被修改 ， 在檢入的時候 ， 也要進行記錄 。 包括： ? 確定元素可以使用的存儲 /增量機制 ? 決定版本選擇的范圍 ， 例如：設(shè)計文檔版本 、 項目管理文檔版本等 ? 適用于不同的配置管理策略 ? 決定比較 、 歸并等的機制 ClearCase已經(jīng)預(yù)先定義了的元素類型 ， 它們主要和存儲機制有關(guān) 。 ? 構(gòu)件的一個版本就是一個基線 。 工作流把一組構(gòu)件基線聚集在一起 。 另一個項目組可以根據(jù)自己的需要 ， 選擇某特定構(gòu)件 ， 確定自己的基線 。 項目的 VOB包含與項目環(huán)境有關(guān)的對象 ， 如：項目 、 構(gòu)件 、 活動以及基線 ， 這些構(gòu)成了一個正在開發(fā)的項目的所有信息 ， 包括項目的組織和管理信息 。統(tǒng)計包括尋找軟件開發(fā)的瓶頸和解決辦法，并據(jù)此衡量軟件產(chǎn)品的成熟度。 ? 由項目經(jīng)理提出請求 ? 由軟件質(zhì)量工程師計劃并實施 ? 對評審過程和標(biāo)準(zhǔn)有專門的文檔規(guī)定 2022/2/16 91 功能評審 ? 功能審核的目標(biāo)是核實軟件配置項的實際性能是否符合它的需求 。 （ 3） 核實是否已對軟件正確應(yīng)用了所有更改 。 （ 2） 檢查在配置管理中維護的項目 。 測試 ClearCase Continuus SourceIntegrity PVCS ? 新代碼 ? 源存儲庫 ? 簡單的版本控制 新開發(fā) PVCS 系列 VSS 部門級開發(fā) 評估 Client/Server環(huán)境的配置管理工具 2022/2/16 110 ? 新代碼 ? 源存儲庫 ? 簡單的版本控制 ? 維護模式 ? 增加的開發(fā)人員 ? 當(dāng)前的開發(fā) ? QA