第一篇：軟件配置管理規(guī)范流程

概述 1.1 目的

本文檔主要目的在于規(guī)范項目配置管理活動，確保配置項正確地唯一標識并且易于存取，保證基線配置項的更改受控，明確基線狀態(tài)，在整個軟件生命周期中建立和維護項目產(chǎn)品的完整性和可追溯性。

1.2 適用范圍

本文檔適用于不同類別的軟件產(chǎn)品和軟件項目開發(fā)工程的配置管理活動，針對項目不同在流程上作適當?shù)膭h減。配置管理可采用各種工具及手工辦法，本文件以CVS（并行版本系統(tǒng)）配置管理工具為例，規(guī)定公司的配置管理辦法，使用其他工具時也可對應本文件的要求參照執(zhí)行。

1.3 術語和縮略語

1.3.1 軟件配置管理（Software Configuration Management，SCM）軟件配置管理是對軟件修改進行標識、組織和控制的技術，用來協(xié)調(diào)和控制整個過程。是通過技術或行政手段對軟件產(chǎn)品及其開發(fā)過程和生命周期進行控制、規(guī)范的一系列措施。配置管理的目標是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個階段都能得到精確的不同版本的產(chǎn)品配置。

1.3.2 配置項（Configuration Item，CI）

凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項，配置項邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以單獨進行設計、實施和測試的。

每個配置項的主要屬性有：名稱、標簽、文件狀態(tài)、版本、作者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程。

1.3.3 基線（Baseline）

在配置管理系統(tǒng)中，基線就是一個配置項或一組配置項在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)，這些配置項構成了一個相對穩(wěn)定的邏輯實體，而這個過程被稱為“基線化”。每一個基線都是其下一步開發(fā)的出發(fā)點和參考點?；€確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項目中的里程碑保持同步。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不能再被任何人隨意修改，對其修改要嚴格地按照變更控制的過程進行。在一個軟件開發(fā)階段結束時，上一個基線加上增加和修改的基線內(nèi)容形成下一個基線。

基線的主要屬性有：名稱、標簽、版本、日期等。1.4 權限與職責 1.4.1 研發(fā)總經(jīng)理助理 1）審核變更請求。

1.4.2 項目經(jīng)理（Project Manager，PM）1)審核批準配置管理計劃； 2)接收或拒絕小范圍的變更申請； 3)召集評估變更；

4)提出配置管理的建議和要求； 5)配合配置管理員的工作。

1.4.3 配置管理員（Configuration Management Officer，CMO）1)編寫配置管理計劃；

2)執(zhí)行版本控制和變更控制方案； 3)制定訪問控制策略；

4)負責項目的配置管理工作，包括搭建環(huán)境、權限分配、配置庫的建立、配置項的控制等；

5)配置管理工具的日常管理與維護； 6)配置庫的日常操作和維護； 7)負責配置審核并提交報告；

8)根據(jù)配置部署表單編譯發(fā)布版本，并維護版本； 9)對開發(fā)人員進行相關的培訓；

10)對配置審核中發(fā)現(xiàn)的不符合項，擬訂糾正措施，要求相關責任人進行糾正。

11)監(jiān)督項目組成員規(guī)范的執(zhí)行情況。1.4.4 開發(fā)人員（Developer）

1)根據(jù)確定的配置管理計劃和相關規(guī)定，提交配置項和基線； 2)負責項目組內(nèi)部測試； 3)負責軟件集成和版本生成；

4)按照軟件配置管理工具的使用模型來完成開發(fā)任務。2 實施細則 2.1 配置項管理 2.1.1 配置項的范圍

軟件配置可包括以下幾方面：開發(fā)文檔，代碼，第三方控件、插件，參考資料，測試文檔，用戶文檔，項目管理文檔，驗收文檔等。

l 項目文檔主要指：立項建議書、可行性分析報告、技術建議書、用戶需求說明書、項目計劃、項目進度計劃、項目階段性計劃、產(chǎn)品需求規(guī)格說明書、概要設計報告、詳細設計、數(shù)據(jù)庫設計、界面設計、用戶操作手冊、用戶安裝手冊、培訓文檔、驗收報告以及上述文檔的評審記錄。

l 代碼主要指：源代碼等。

l 工具主要指：腳本文件、插件、第三方控件等。2.1.2 配置項基線管理

結合SPP和ISO9000的相關規(guī)定，配置管理員根據(jù)配置管理規(guī)范及配置管理計劃，對配置項進行分階段管理，每一階段正式評審通過后納入受控庫，作為該項目的一個基線。

l 項目啟動：配置項包括技術建議書、可行性分析報告、用戶需求說明書等立項階段產(chǎn)生的文檔，評審或?qū)徟ㄟ^后建立發(fā)布基線。

l 需求階段：系統(tǒng)調(diào)研后開發(fā)人員進行需求分析，并整理產(chǎn)品需求規(guī)格說明書。產(chǎn)品需求規(guī)格說明書經(jīng)過客戶的確認后，建立需求基線。如需升級版本則必須通過評審或?qū)徟⒌玫娇蛻舻拇_認。

l 項目計劃：需求分析完成后即可制定項目的開發(fā)計劃，包括項目計劃和主要下屬計劃。包括項目進度計劃、配置管理計劃、質(zhì)量保證計劃、測試計劃、項目階段性計劃。項目開發(fā)計劃評審通過后，建立項目計劃基線。

l 設計：系統(tǒng)設計可分為概要設計、詳細設計、數(shù)據(jù)庫設計、數(shù)據(jù)庫字典、界面設計。針對用戶需求規(guī)格說明書進行系統(tǒng)設計，配置時應說明系統(tǒng)設計的版本與需求分析報告版本的對應關系。設計說明書評審或?qū)徟ㄟ^后，建立設計基線。l 編碼（設計實現(xiàn)）：編碼按功能模塊分子項目，即每個模塊記作一個配置項。代碼在提交項目組系統(tǒng)測試時建立Beta版本，系統(tǒng)測試產(chǎn)品正式發(fā)布后建立Version版本。

l 測試：單元測試和系統(tǒng)測試。單元測試通過提交《單元測試報告》，項目啟動后應提交《系統(tǒng)測試計劃》，系統(tǒng)測試完成后應提交《系統(tǒng)測試報告》。配置時應說明測試的版本與編碼版本的對應關系。系統(tǒng)測試完成后建立測試基線。

l 版本發(fā)布：項目組提交《部署表單》，CMO根據(jù)部署表單進行編譯，發(fā)布測試服務器上，并對版本進行維護。同時將發(fā)布的版本上傳到文檔服務器上備份。

l 交付與驗收：在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關文檔配置項，包括交付文檔、代碼、工具等。

l 產(chǎn)品部署：部署時應包括操作手冊、安裝維護手冊、維護文檔以及必要的業(yè)務和技術培訓文檔。

l 相關資料：相關資料也應作為配置項納入配置管理，此部分包括： 1)相關法律、法規(guī)；必須遵照或項目組約定的技術規(guī)范；

2)與客戶或項目組內(nèi)部重要的交互信息記錄，如會議記錄、會談記錄、e-mail和MSN記錄等；

2.2 版本控制 2.2.1 文檔的版本控制

所有文檔的管理納入配置管理庫，用版本控制工具進行統(tǒng)一管理。文檔的版本控制主要通過文檔的名稱、文檔控制頁及版本控制工具的標簽來實現(xiàn)，主要分為以下幾類：

2.2.1.1 版本變化型文檔

命名方式：[文檔名稱]+[子系統(tǒng)名稱]（可選）

適用文檔：項目計劃、配置管理計劃、質(zhì)量保證計劃、項目進度計劃、用戶需求規(guī)格說明書、產(chǎn)品需求規(guī)格說明書、體系結構設計報告、數(shù)據(jù)庫設計報告、詳細設計報告、用戶操作維護手冊、測試用例等。

示例：項目計劃.doc 詳細設計_SP門戶.doc 標簽結構：[大版本] + [子系統(tǒng)簡稱] + [版本號] + 日期（標簽控制說明版本信息）

l [大版本]： 可選，表示同一項目為不同用戶定制的版本。l [子系統(tǒng)簡稱]： 可選，當一個項目有多個子系統(tǒng)時，為區(qū)分不同子系統(tǒng)而設置。

l [版本號]：采用[Vs_x_y]的形式。

l 日期：納入基線管理的日期，用8位表示，如20071031 說明：

a.文檔發(fā)布名稱采用[文檔名+ Vs_x_y]的形式，文檔的版本號應該和版本控制工具中相應標簽上的版本號一致。

b.對文檔的修改需要從配置管理庫中取到本地進行。

c.對于文檔小的修改，如文字錯誤，格式調(diào)整，變更Vs_x_y中的y來區(qū)別（如：V1_0_1）。

d.文檔內(nèi)容沒有大的增加和刪節(jié)，意思表述沒有發(fā)生重大的變化，版本標識通過版本工具中加上x標簽來表示（如：V1_1_0），以及在文檔內(nèi)部控制頁標注變化來表示。

e.文檔有重大增加和刪節(jié)，意思表述有重大變化的，版本標識通過在相應文檔加上s標簽來表示（如：V2_0_0）。

f.對于納入基線庫的文檔的修改需要提交變更申請，經(jīng)批準才能進行修改，并且修改的內(nèi)容要經(jīng)再次評審才能重新納入基線庫，作為后續(xù)階段的參考文檔。

2.2.1.2 時間區(qū)別型文檔 命名方式：[文檔名稱＋撰寫時間] 適用文檔：文檔名稱有明確的含義，需要用時間標識的日常性文檔。如周例會會議紀要，項目月計劃，項目月總結,階段性計劃等等。

示 例：周例會會議紀要20030901.doc 2.2.1.3 時間序號型文檔

命名方式：[文檔名稱+人員姓名（拼音）+撰寫時間+序列號] 適用文檔：測試報告

示例：單元測試報告_lixiaohong_20071112_01.dco 2.2.1.4 其他文檔：

對于不能按照前四種類型進行命名的文檔 會議紀要：會議紀要YYYYMMDD()示 例：9月9日召開的項目啟動會 命名為：會議紀要20030909(項目啟動).doc 評審報告：評審報告YYYYMMDD()同”會議紀要”要求一致。

示 例：10月9日召開的項目總體方案評審 命名為：評審報告20030910(總體方案).doc 2.2.2 發(fā)行版本表示

發(fā)行版本采用標簽說明，結構如下：

[大版本] + [版本類型] + [版本號] + [子系統(tǒng)簡稱(拼音)]+日期 +序號 [大版本]： 可選，表示同一項目為不同用戶定制的版本。

[子系統(tǒng)簡稱]： 可選，當一個項目有多個子系統(tǒng)時，為區(qū)分不同子系統(tǒng)而設置。

版本類型：分為3種

Beta表示項目組內(nèi)部測試，標簽：B1_0_0-20071015-01 Release系統(tǒng)測試，標簽：Release1_0_0-SPmenhu-20071112-01 Version正式發(fā)行版，標簽：Version1_0_0-SPmenhu-20071112-01 [版本號] 對于Version正式發(fā)行版 是必須要注明的，而其它可選。發(fā)行產(chǎn)品基線在版本號前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的標簽； Version_0_0, Version_0_1, Version_0_2… 表示在主線上的標簽。2.3 配置庫管理 2.3.1 配置庫的分類

配置庫統(tǒng)一由配置管理員負責管理，服務器端使用cvsnt2.0.4，客戶端主要使用烏龜CVS。配置庫目錄結構如下：

2.3.2 配置庫的建立 所有項目應建立配置庫，以便管理各配置項，配置管理員組織建立配置庫。程序庫主要通過設置版本的分支來實現(xiàn)對配置項權限管理：

1)開發(fā)庫：開發(fā)人員相對比較自由的存儲空間，開發(fā)人員可以在自己的權限范圍內(nèi)任意取出提交。

2)基線庫：配置管理員有最高權限，其余相關人員均為讀的權限，發(fā)生變更時變更人員須提交變更申請后方可修改基線庫內(nèi)的配置項。

? 文檔評審通過后，文檔嚴格受控。由配置管理員將通過評審后的文檔移植到基線庫里同時將該配置項從開發(fā)庫移除。

? 代碼一般在移交系統(tǒng)測試時納入基線庫受控，可根據(jù)項目的具體情況設置基線。

3)產(chǎn)品庫：產(chǎn)品庫的產(chǎn)品均出自于基線庫，產(chǎn)品庫存儲的產(chǎn)品用于交付和存檔。

配置三庫統(tǒng)一由配置管理員管理，根據(jù)各開發(fā)階段的實際情況定制相應的版本選取規(guī)則，來保證開發(fā)活動的正常運作。在變更發(fā)生時，應及時做好基線的推進。

2.3.3 分配權限

項目開始后配置管理員編寫《配置庫目錄結構表》明確項目組成員以及相關人員的權限。在wincvs里有三種權限，讀（r）、寫（w）、添加刪除（c）權限。在開發(fā)庫內(nèi)，文檔部分項目組成員有rcw權限，其他相關人員只r權限；代碼部分項目組成員有rcw權限，其他相關人員沒有任何權限。在基線庫內(nèi)，項目組成員僅有r權限，其他相關人的權限視情況而定。在產(chǎn)品庫內(nèi)，所有人沒有任何權限。配置管理員在三庫內(nèi)均擁有最高權限。

2.4 配置變更控制 2.4.1 變更的分類

軟件及其相關文檔的變更按照變更的影響范圍進行分類：

1)A級：變更會影響系統(tǒng)級的需求、外部接口、產(chǎn)品價格或者交付期；這類變更必須經(jīng)過配置管理委員會審核并有客戶批準和確認。

2)B級：變更會影響配置項間的功能接口、內(nèi)部功能的設計、組件；這類變更必須由項目經(jīng)理或配置管理委員會的批準和認可。3)C級：變更只會影響配置項內(nèi)部或?qū)UG問題的處理；這類變更可以由配置項的管理人員負責批準。

? 系統(tǒng)測試前變更控制流程：

? 系統(tǒng)測試完畢發(fā)布release版本后變更控制流程

圖2 變更控制流程 2.4.2 變更請求的提出

a． 由技術支撐中心匯集顧客意見，影響到需求變更則填寫《配置項變更控制報告》，并提交給配置管理員。

b． 配置管理員對申請表是否清晰、明確和完整性進行審查，若發(fā)現(xiàn)變更不明確或不完整，應返回申請者。對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息。

2.4.3 評估變更

a． 配置管理員將《配置項變更控制報告》發(fā)送給項目經(jīng)理（或者其他授權人員），由項目經(jīng)理負責對變更進行評估。

b． 項目經(jīng)理對變更進行分解，一般的BUG修正不需要審批直接由項目經(jīng)理決定是否需要變更。新增功能或?qū)φ麄€項目影響重大的變更必須由研發(fā)總助審批通過后方可變更。變更評估文檔在完成變更評估后發(fā)送給配置管理員。

2.4.4 變更實施和確認

a． 變更被批準后，項目經(jīng)理提交變更實施進度計劃，開發(fā)人員開始實施變更，并詳細記錄變更的內(nèi)容；質(zhì)量部對變更的實施進行跟蹤。

b． 對于代碼變更，必須進行回歸測試，以確保變更沒有引入新的Bug。另外與變更相關的文檔必須修訂，以反映變更。當變更以及測試完成后，進行提交。

c． 通過測試后，質(zhì)保人員需對變更進行審核，審核的范圍一般涉及以下方面：測試記錄；變更請求；配置項的檢入及檢出；文件的命名；版本的編號。

a． 審核后，由配置管理員更新到基線庫中。2.5 配置狀態(tài)報告 2.5.1 目的

記錄和報告整個軟件生命周期演化狀態(tài)。2.5.2 記錄內(nèi)容

配置狀態(tài)報告記錄的內(nèi)容包括： 1)軟件和文檔的標識； 2)目前狀態(tài)； 3)基線演化狀態(tài)； 4)變更狀態(tài)； 5)版本交付信息等。2.5.3 生成報告

配置管理報告自第一個基線創(chuàng)建時建立，由配置管理系統(tǒng)生成，及時反映當前配置狀態(tài)。

2.6 配置審核 2.6.1 類別 配置審核分為：

1)功能配置審核（Functional Configuration Audit，F(xiàn)CA）：審核軟件功能是否與需求一致，并符合基線文檔要求，通常要審查測試文檔等。

2)物理配置審核（Physical Configuration Audit，PCA）：審核要交付的組成項是否存在，是否包含所有必需的項目，如正確版本的源代碼、資源、文檔、安裝說明等等。

2.6.2 執(zhí)行時機

通常選擇以下幾種情況由質(zhì)量保證人員負責實施配置審核： 1)軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前； 2)軟件開發(fā)的階段工作結束后； 3)在產(chǎn)品維護工作中，定期地進行。2.6.3 不符合項處理

對配置審核中發(fā)現(xiàn)的不符合現(xiàn)象，配置管理員進行記錄，并交由責任部門限期進行糾正，配置管理員負責糾正措施的驗證。所有的不符合項報告均關閉后，才能發(fā)布新版本。

2.7 發(fā)行管理

通過配置審核后，經(jīng)項目經(jīng)理批準，由配置管理員負責生產(chǎn)新版本。2.7.1.1 交付管理

這里“交付”是指從配置庫中提取配置項，交付給客戶或項目外的人員。交付出去的配置項必須有據(jù)可查，避免發(fā)生混亂。流程如下：

1)交付人向質(zhì)量部申請；

2)質(zhì)量部如果不同意交付，則拒絕交付配置項。如果同意交付，配置管理員應給出詳細的交付清單；

3)交付人驗收后簽字。

第二篇：規(guī)范軟件開發(fā)過程——軟件配置管理實踐

規(guī)范軟件開發(fā)過程——軟件配置管理實踐

2010-05-19 來源：網(wǎng)絡

隨著軟件系統(tǒng)的規(guī)模、復雜度日益上升，軟件開發(fā)過程管理已經(jīng)成為保證軟件系統(tǒng)開發(fā)效率、質(zhì)量、成本的關鍵性因素。作為軟件開發(fā)過程中質(zhì)量保障的重要組成部分，行之有效的軟件配置管理（以下簡稱SCM，Software Configuration Management）能夠顯著提高軟件開發(fā)組織的自身能力、提高軟件開發(fā)過程的完整性，以及降低軟件開發(fā)的風險。

軟件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983對SCM的定義有不同的描述。ISO9000定義SCM為“一個管理學科，它對配置項的開發(fā)和支持生命周期給予技術上和管理上的指導。配置管理取決于項目的規(guī)模、復雜程度和風險大小”。

CMM2將SCM定義為一個關鍵過程域KPA，是“貫穿于整個軟件過程中的保護性活動，它被設計來（1）標識變化，（2）控制變化，（3）保證變化被適當?shù)陌l(fā)現(xiàn)（4）向其他可能有興趣的人員報告變化?！?。SCM包括了配置項識別、工作空間管理、版本控制、變更控制、狀態(tài)報告、配置審計等活動，其中以版本控制最為核心和關鍵。

數(shù)據(jù)集中工程軟件配置管理策略

1、數(shù)據(jù)集中工程項目背景

中國建設銀行數(shù)據(jù)集中工程的目標是通過建立總行級的數(shù)據(jù)中心，向全行38個一級分行、20000多個網(wǎng)點提供完整的核心金融服務。其核心應用系統(tǒng)DCC-CCBS包括主機、前置、前端三大部分。主機應用部分部署在總行級數(shù)據(jù)中心，前置應用部分部署在數(shù)據(jù)中心前置通信網(wǎng)關、各一級分行業(yè)務大前置，前端部分部署在網(wǎng)點。

DCC-CCBS項目的SCM需要實現(xiàn)開發(fā)、發(fā)布、部署的全過程軟件配置管理。開發(fā)過程SCM的核心是系統(tǒng)源碼版本管理；發(fā)布過程的SCM核心是系統(tǒng)目標碼版本管理；部署過程以確保系統(tǒng)目標碼版本在數(shù)據(jù)中心、一級分行、網(wǎng)點和外系統(tǒng)的正確部署為首要目標。

2、開發(fā)過程軟件配置管理

系統(tǒng)源碼版本除系統(tǒng)源程序、參數(shù)外，還包括需求規(guī)格說明書、系統(tǒng)總體架構設計說明書、主機/前置/前端系統(tǒng)結構設計說明書、各子系統(tǒng)的詳細設計說明書、各子系統(tǒng)的對外接口規(guī)范、業(yè)務操作手冊、系統(tǒng)使用手冊、系統(tǒng)安裝維護手冊等文檔。根據(jù)配置項的不同屬性，經(jīng)過評審，形成需求基線、設計基線和源代碼基線等不同的基線。開發(fā)過程SCM按照子系統(tǒng)的性質(zhì)，分為主機、前置、前端三部分獨立管理。

DCC-CCBS項目總體組負責整個需求和變更的控制。通過審批的需求按照功能分布分解為主機、前置、前端的子需求，再由各部門分別管理和實現(xiàn)。環(huán)境及版本控制小組負責向各部門提出形成“系統(tǒng)基線”的要求，以同步主機、前置、前端的源碼版本。

3、發(fā)布過程軟件配置管理

發(fā)布過程的系統(tǒng)目標碼版本包括系統(tǒng)目標碼（執(zhí)行碼）、系統(tǒng)參數(shù)及相關文檔等。按照用途，系統(tǒng)目標碼版本可分為測試版和正式版。以前置平臺為例，發(fā)布過程SCM的主要活動包括：構建環(huán)境管理，保證編譯環(huán)境的純凈性和正確性；

構建過程管理，保證構建過程的自動化操作，及其正確性和完整性；

版本編號管理，統(tǒng)一版本命名規(guī)則，確保目標碼版本號的唯一性和可追蹤性；

目標碼版本生成管理，從各版本管理工具系統(tǒng)收集、整理、打包相應的目標碼、參數(shù)和文檔，形成完整的或部分（補丁）的目標碼版本；

配置狀態(tài)檢查，檢查目標碼版本包中內(nèi)容的正確性、完整性和一致性；

4、部署過程軟件配置管理

部署過程SCM的主要任務是：建立安全、可靠和迅速的傳輸流程和傳輸渠道；建立目標碼版本記錄和追蹤機制、版本運行時刻檢查機制和版本恢復機制；確保正確的版本、按照正確的渠道、在規(guī)定時間遞交到正確的用戶并生效。

在DCC-CCBS生產(chǎn)環(huán)境中，軟件開發(fā)中心將通過數(shù)據(jù)中心版本管理系統(tǒng)發(fā)布各單位所需的目標碼版本，各單位在版本管理系統(tǒng)和數(shù)據(jù)傳輸通道的支持下，實現(xiàn)版本/補丁的主動分發(fā)、查詢、下載和生效。

軟件配置管理實施經(jīng)驗

1、樹立正確的企業(yè)配置管理意識

SCM是一門管理學科。歸根結底，其關鍵是“管理”，然后才是“軟件配置”。項目級SCM能否成功實施，與企業(yè)的軟件配置管理目標、策略、能力、組織和資源息息相關。

2、提高全員的配置管理素質(zhì)

SCM是規(guī)則和流程的集合，需要依靠流程中所有部門和人員共同的支持和努力。任何環(huán)節(jié)上的疏忽和懈怠，都將直影響SCM的實施效果。

3、采用合適的工具

功能強大的或昂貴的工具未必是合適的工具。往往20%的功能即可解決80％的配置管理問題。目前比較流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在選擇具體工具時，往往需要考慮以下因素：（1）工具將要使用的范圍；（2）工具自身的功能、穩(wěn)定性、擴展行，以及對環(huán)境的要求；（3）工具使用的復雜度；（4）工具與其他流程和工具的集成度和交互性；（5）工具的投資和維護費用。

4、及時的檢查和梳理

大系統(tǒng)開發(fā)過程中，配置管理往往采用分步離散管理方式，因此保證整個系統(tǒng)配置管理的完整性成為一件精密細致的工作，需要投入大量人力及時修訂基線，防微杜漸，避免混亂，以滿足對配置管理正確性、完整性和及時性的要求。

5、系統(tǒng)化思考、分步實施、持續(xù)改進

SCM不是一項孤立的管理活動。企業(yè)的戰(zhàn)略目標、管理能力、文化背景、組織結構，項目的規(guī)模、性質(zhì)、技術、人員等都是影響SCM決策的重要因素。因此需要在項目乃至企業(yè)的整體環(huán)境中系統(tǒng)的考慮SCM的實施策略和方法。

通過分階段實施量化的、漸進的配置管理目標，可以避免由于引入復雜管理流程所造成的混亂，有利于方便靈活地優(yōu)化配置管理流程。同時，階段性目標的實現(xiàn)將有助于整個團隊提高士氣、增強信心，并逐步提高開發(fā)隊伍的配置管理素質(zhì)。

第三篇：軟件配置管理解決方案

軟件配置管理解決方案

目的:

● 通過使用配置管理軟件,遵守版本控制、變更控制等規(guī)程,保證所有配置項的完整性和可跟蹤性。

范圍:

● 適用于公司的軟件開發(fā)項目,它規(guī)定了軟件配置管理活動的具體規(guī)程及其工作產(chǎn)品。

角色與職責:

● 配置管理員:編制項目配置管理計劃；創(chuàng)建并維護配置庫。

● 配置變更控制委員會(SCCB):審批配置變更申請。

● 軟件開發(fā)組成員:在權限內(nèi)使用配置管理工具操作配置庫。

● 項目SQA人員:審計配置管理活動的規(guī)范性。

進入準則:

● 項目計劃已制定。

● 項目軟件過程已定義

● 配置管理員和SCCB人員已確定。

輸入:

● 項目計劃

● 項目軟件過程

結束準則:

● 對項目配置庫的操作和管理持續(xù)到項目結束。

● 只要存在用戶使用配置管理就要進行。

輸出:

● 配置管理計劃

● 產(chǎn)品配置庫

● 軟件基線審計報告

主要活動: 在項目早期(在項目計劃初稿后,并與項目計劃一起評審)編制項目配置管理計劃。

● 確定項目配置管理員。

● 項目經(jīng)理和項目配置管理員共同指定項目組的SCCB。

● 項目經(jīng)理與項目配置管理員按確定的軟件生命周期,識別出項目要進行控制的軟件配置項和納入配置管理的日期。

● 項目經(jīng)理與項目配置管理員依據(jù)項目定義軟件過程,共同確定項目的基線,并標識每個基線的配置項。

● 項目經(jīng)理確認由項目配置管理員制定的在軟件生命周期各個階段配置項的使用權限清單。

● 項目配置管理員按照《配置管理計劃模板》制定項目的SCM計劃。

● 項目配置管理員根據(jù)項目所使用的開發(fā)工具確定項目使用的配置管理工具。

● 項目配置管理員根據(jù)項目計劃的變動,適時調(diào)整項目的SCM計劃。具體規(guī)程見《項目跟蹤與監(jiān)控過程》計劃變更相關步驟。

● 由項目主管主持,項目經(jīng)理、公司配置管理主管、項目配置管理員、軟件工程組、軟件相關組參加對配置管理計劃書的評

審。具體規(guī)程參見《同行評審過程》。

按照配置管理計劃,進行項目的配置庫管理。

● 項目配置管理員規(guī)劃、建立項目的目錄結構。該結構支持對配置項的存儲和檢索功能。

● 項目配置管理員根據(jù)項目的規(guī)模,規(guī)劃和配置管理工具相關的配置庫結構。

● 項目配置管理員依據(jù)經(jīng)項目經(jīng)理確認的權限清單對目錄結構進行權限分配,以達到在相關組之間或配置庫內(nèi)部之間進行共

享和傳輸。

● 項目配置管理員將配置項用配置管理工具統(tǒng)一管理,將軟件工作產(chǎn)品存放在指定的服務器的軟件基線庫中。

● 項目配置管理員保證由軟件基線庫制造的產(chǎn)品的正確生成。

● 公司配置管理員定期對服務器的軟件開發(fā)庫、軟件基線庫進行備份,對配置項的歸檔版本提供存儲和恢復功能。3 配置識別

● 項目配置管理員在制定項目的SCM計劃時,與項目經(jīng)理共同識別出將置于配置管理之下的軟件工作產(chǎn)品?？蓸俗R為配置項的 軟件工作產(chǎn)品的例子有:

◇與過程有關的文檔；

◇軟件需求；

◇軟件設計；

◇軟件源代碼；

◇軟件可執(zhí)行代碼；

◇軟件測試規(guī)程；

◇為軟件測試活動建立的軟件系統(tǒng)；

◇編譯程序；

◇交付給用戶的或最終用戶的軟件系統(tǒng)；

◇其它支持工具等。

● 項目配置管理員依據(jù)項目配置計劃書在給定的時間點上標識配置項/單元。

● 項目配置管理員依據(jù)開發(fā)規(guī)范,保證每個配置項賦予唯一的標識符。

● 項目組成員應用配置管理工具,標明每個配置項的修訂版本號。

● 項目配置管理員可用配置管理工具中的label功能,說明每個配置項所屬的軟件基線。

● 項目配置管理員使用配置管理工具記錄每個配置項/單元置于軟件配置管理之下的時間,并標明其生成者。配置變更

● 變更分類

對軟件及其相關文檔的變更按照變更的影響范圍進行分類:

1)A級:變更會影響系統(tǒng)級需求、外部接口、產(chǎn)品價格或者交付期；這類變更必須經(jīng)過SCCB審核并有客戶批準和確認。

2)B級:變更會影響配置項間的功能接口、組件級成本或者項目Schedule；這類變更必須由SCCB或上級管理部門的批準和認可。

3)C級:變更會影響配置項內(nèi)部功能的設計和分配；這類變更可以由配置項的管理人員負責批準。

● 變更請求的提出

◇如果需對已納入基線管理的配置項提出修改,項目組或其他相關人員應在配置項變更請求評審記錄中填寫變更請求,交給項目

經(jīng)理。相關表格參見《配置項變更申請單》。

◇項目經(jīng)理組織人員對變更請求進行評估,描述實施變更所影響的配置項、文檔和資源,確定變更的分類；如果是屬于A類

或B類,需要組織SCCB評審會進行評審。

● 變更實施

◇項目經(jīng)理將需解決并批準的問題通知相關人員進行修改。

◇項目組成員實施《配置項變更申請單》中的所有變更,并確保相關文檔得到更改。

◇測試人員對已修改的問題進行確認,并將跟蹤結果記入CQ中。

◇當確認無誤后,項目組成員檢入配置庫。

◇項目配置管理員跟蹤配置項變更解決的過程。跟蹤的主要內(nèi)容有:

1)解決人；

2)解決日期；

3)解決方法；

4)修改的文件；

5)受影響的文件；

6)受影響的數(shù)據(jù)；

7)是否經(jīng)過驗證等。

● SCCB定期召開評審會,確認基線修改的正確性、完整性和一致性,并保證不會對基線造成意外的后果。保證由軟件基線庫生成產(chǎn)品并控制它們的發(fā)行。

● 項目經(jīng)理或指定人員依據(jù)SDP中的build計劃和軟件產(chǎn)品測試申請單,對存放于軟件配置庫中的源程序進行編譯,生成軟件產(chǎn)

品,并提交測試人員進行測試。

● 測試人員依據(jù)產(chǎn)品測試通過標準,對待測產(chǎn)品進行確認測試,形成測試報告。

● SCCB依據(jù)測試報告,審計由軟件基線庫生成的軟件產(chǎn)品與測試通過標準的符合性,并生成SCCB會議紀要。

● 對審計通過的產(chǎn)品build,項目配置管理員將其升級為基線。

● 項目配置管理員對審計通過的軟件工作產(chǎn)品建立版本標識號(用配置管理工具的label加以標識)。

● 項目配置管理員將審計通過的軟件產(chǎn)品(release)放入軟件產(chǎn)品庫。

當軟件工作產(chǎn)品納入基線管理時,進行軟件基線審計。

● 根據(jù)項目配置管理計劃,SCCB確認在適當?shù)臅r間需要審計的軟件基線,明確該基線包括的配置項。

● 在該基線包含的配置項經(jīng)評審和檢查通過后,項目配置管理員通過配置管理工具將配置項升級為基線狀態(tài),并為配置項標注

LABEL等。該基線所包含的所有配置項都升級為基線狀態(tài)時,該基線正式建立。

● 項目配置管理員驗證該基線是按照項目的配置管理計劃所明確的配置項組成的。

● 項目配置管理員驗證已建立的基線所包含的配置項是完備、準確的。

● 項目配置管理員將審計發(fā)現(xiàn)的問題記入基線審計報告,并對問題進行跟蹤直至解決。

● 項目配置管理員將基線審計報告向項目經(jīng)理報告。

過程裁剪說明:

◆創(chuàng)建配置庫時,庫結構需要使用公司統(tǒng)一目錄結構,但是項目可以根據(jù)需要增加目錄結構；除在公司外部連接不到公司服務器情況

外,不可以使用公司規(guī)定以外的配置管理工具。

相關文檔:

◆配置管理計劃模板

◆配置項變更申請表表樣

◆軟件基線審計報告表樣

第四篇：軟件項目的配置管理

軟件項目的配置管理

[摘要]：

2004年6月，我作為項目經(jīng)理開始參與某航空公司航空票務系統(tǒng)項目的開發(fā)，主要負責系統(tǒng)的組織規(guī)劃實施開發(fā)與項目管理，該系統(tǒng)具有嚴格的安全，穩(wěn)定，時實高效和可靠性能要求，該系統(tǒng)由票務管理系統(tǒng)和呼叫中心系統(tǒng)兩部分組成，呼叫中心系統(tǒng)主要實現(xiàn)電話，傳真和短信業(yè)務，票務管理系統(tǒng)是整個系統(tǒng)的核心，采用了struts+hibernate+spring主流WEB應用框架，實現(xiàn)了WEB應用服務器websphere與協(xié)作應用服務器lotus domino 的高度集成.隨著軟件系統(tǒng)的日益復雜化和用戶需求，軟件更新的頻繁化，配置管理在軟件項目中顯得越來越重要了。本文以該項目為例，結合作者時間，主要通過在項目前期，做好需求調(diào)研，總體設計和詳細設計并制定完整的配置管理計劃。在該項目全過程中規(guī)范化配置管理，注意員工培訓并加強溝通與協(xié)調(diào)，來實施項目的配置管理。目前，該系統(tǒng)已開發(fā)完畢，正式投入運行，狀況良好，受到客戶一致好評。

[正文]：

2004年6月，2004年6月，我作為項目經(jīng)理開始參與某航空公司航空票務系統(tǒng)項目的開發(fā)，主要負責系統(tǒng)的組織規(guī)劃實施開發(fā)與項目管理，當然還做一些編碼工作，主要是公用基礎代碼和核心代碼的編寫與維護。航空票務系統(tǒng)是將呼叫中心系統(tǒng)和票務管理系統(tǒng)有效的結合起來，采用先進的ＣＴＩ技術和語音板卡技術，充分利用電話，短信，傳真，因特網(wǎng)等信息化手段，解決航空公司的機票銷售問題，規(guī)范了業(yè)務流程，強化了內(nèi)部管理，與電子商務的完美結合，使應用系統(tǒng)功能更加完善，提高了整個航空業(yè)務的工作效率。其中，票務管理系統(tǒng)包括：客戶管理，機票管理，票證管理，銷售管理，財務結算，調(diào)度管理，遠程營業(yè)部（代理商／分銷商）管理，系統(tǒng)管理八大功能模塊，并統(tǒng)一于服務器端軟件模塊。呼叫中心系統(tǒng)由電話呼叫系統(tǒng)，短信分發(fā)系統(tǒng)，傳真呼叫系統(tǒng)三部分組成。票務管理系統(tǒng)是整個系統(tǒng)的核心，采用了struts+hibernate+spring主流WEB應用框架，實現(xiàn)了WEB應用服務器websphere與協(xié)作應用服務器lotus domino 的高度集成,在本次開發(fā)中，我把它視為整個項目的重點

由于考慮到寒假和春運期間將會是旅客的高峰期，客戶要求系統(tǒng)必須在12月底前交付，項目開發(fā)周期為6個月，為此我做了如下安排：前4個月主要集中精力用于開發(fā)票務管理系統(tǒng)，后兩個月主要完成票務管理系統(tǒng)和呼叫中心系統(tǒng)的集成以及項目收尾工作

隨著軟件系統(tǒng)的日益復雜化和用戶要求，軟件更新的頻繁化，配置管理逐漸成為軟件生命周期中的主要控制過程。在軟件開發(fā)過程中，扮演越來越重要的角色。一個好的配置管理過程能覆蓋軟件開發(fā)和維護的各個方面，同時對軟件開發(fā)過程的客觀管理，即項目管理也有重要的支持作用。在該系統(tǒng)項目中，我主要使用intersolv公司的pvcs配置管理工具，并通過在項目前期作好需求調(diào)研，總體設計和詳細設計并制定完整的配置管理計劃。在項目全過程規(guī)范化配置管理，注意員工培訓并加強溝通與協(xié)調(diào)等方法和策略來實施配置管理。項目前期做好要求調(diào)研，總體設計和詳細設計，并制定完整的配置管理計劃。

項目計劃階段，我對需求分析，總體設計和詳細設計這三項活動工期安排如下：需求分析12天，總體設計和詳細設計總共20天，時間盡量充足。在做需求調(diào)研的時候，我要求一定要和客戶充分溝通，深入挖掘客戶的隱性需求。不僅要實現(xiàn)客戶需求的功能，在界面上也要讓客戶滿意，為此我們作出了航空系統(tǒng)的虛擬界面，讓客戶對系統(tǒng) 有一個感官上的整體了解，在需求分析完成工作之后，我們還通過小組會議的形式進行了確認和評審。并邀請客戶方代表參與。最終的《需求規(guī)格說明》我們也要求客戶方代表一定要簽字確認。在總體設計和詳細設計過程中，我們盡量使用適合本項目團隊特點的工具和技術，并充分考慮其先進性和成熟性。在設計完成之后，我們?nèi)耘f對其進行了評審，總結和討論，對爭議比較大的地

方交公司資深專家審核評定。

配置管理計劃的制定也使配置管理中不可少的一步，它能有效的指導后期配置管理工作。在本項目中，配置管理計劃由配置管理員完成，我只做一些審核工作，軟件資源配置管理計劃，配置項目計劃，交付計劃，備份計劃，CCB審批計劃等．．．．總之，我認為項目前期做好以上鋪墊工作可以減少變更，對后面一些工作可以說是水到渠成。同時，一個比較完整的計劃，也可以避免不必要的項目反工，而且項目管理員的工作也會比較好做一些。項目全過程規(guī)范化配置管理。

開發(fā)過程中，對文檔修改非常麻煩，在配置管理中，對任何一配置項的修改都可能導致版本的變化。因此，對配置管理規(guī)范化勢在必行，在本項目中，我要求配置標識一定要規(guī)范，必須獨立命名配置項，配置對象的標識要充分考慮命名對象間存才聯(lián)系。在配置管理中，項目組成員要各司其職，不得越權操作，同時還要根據(jù)自己的權限操作配置項。我的工作在配置管理中主要是：定制開發(fā)子系統(tǒng)，定制訪問控制，制定常用策略，制定集成里程碑，進行系統(tǒng)集成．．．．．而配置管理員的職責主要是：創(chuàng)建配置序，為項目成員分配權限，對存儲庫進行日常備份恢復等．．．軟件開發(fā)人員主要根據(jù)項目的開發(fā)配管理策略，創(chuàng)建，修改和測試工件等。軟件生存期內(nèi)全部軟件配置是軟件產(chǎn)品的真正代表，必須保持精確，軟件工程中某一階段的變更都會引起軟件配置的變更，對這種變更也必須做到嚴格規(guī)范的控制和管理。為此，我做了如下規(guī)定：處于工作狀態(tài)的產(chǎn)品開發(fā)人員可對其修改，而作為基線進入配置庫的產(chǎn)品，則不允許開發(fā)人員對其進行修改。在本項目中，我們還成立了臨時CCB,由項目經(jīng)理，用戶代表，軟件質(zhì)量控制人員，配置管理員5人組成。我們要求對于用戶提出的變更請求要嚴格按照變更控制流程處理。在用戶提交更多請求后，開發(fā)人員對其進行評價，并產(chǎn)生變更報告。在由變更控制委員會〈CCB〉作出決定是否進行變更。通過批準，就重新檢出變更的配置項，建立測試基準程序，并執(zhí)行質(zhì)量保證和測試活動，必須通過CCB的鑒定審批后，方可實施變更。

注意員工培訓并加強協(xié)調(diào)與溝通。

項目組成員大多來自不同部門，對項目環(huán)境還不熟悉，為了能實施配置管理系統(tǒng)，我建議公司對項目組成員進行相關培訓。針對配置管理員，我們要求他學習配置管理工具管理相關的內(nèi)容。針對開發(fā)人員，主要學習配置管理工具與開發(fā)相關的常用操作。針對全體人員，要讓他們了解配置管理策略和流程，以及如何與開發(fā)管理，項目管理相結合。同時，我要求項目組成員要加強協(xié)調(diào)和溝通?？梢允褂肞VCS，通過ressionmanger文檔共享和連鎖機制。Tracker與電子郵件的集成，加強項目成員之間的溝通，做到有問題及時發(fā)現(xiàn)，及時修改，及時通知，但又不額外增加很多的工作量，這樣有助于營造一個和諧，公平，競爭的氣氛和環(huán)境。

航空票務系統(tǒng)在2004年12月下旬正式上線，提前完成了項目，目前系統(tǒng)運行正常，受到客戶和有關部門的一致好評，對項目的滿意度較高。重新回顧該項目也存在一些問題不足，比如：項目初期，大多數(shù)成員對版本管理一點都不重視，總是敷衍了事。代碼編寫人員編寫得代碼也混亂不堪，給測試人員和維護人員帶來了很大不便，一些沒多大用的垃圾資料也被放置到配置服務器上，給配置管理人員帶了很多麻煩。因此我建議在項目一開始，就要讓項目成員認識到版本管理的好處。對源碼的管理，要保證書寫代碼的規(guī)范性，強化注釋力度，還應作好build和relase工作.

第五篇：軟件配置管理最佳實踐

軟件配置管理最佳實踐

PMTeam雜志 Li Ben 編

現(xiàn)在大家都已經(jīng)認識到了有效的軟件配置管理工作對于提高團隊開發(fā)效率、保障軟件產(chǎn)品質(zhì)量的重要意義，很多朋友也開始了在配置管理實施方面的一些研究，市場上我們也可以看到一些軟件配置管理工具廠商針對具體配置管理工具提供的實施服務；但是，實施軟件配置管理到底應該做哪些東西？團隊的配置管理現(xiàn)狀怎么評估？在哪些方面還可以進行改進？我們相信，這些問題可能正困擾著大多數(shù)研發(fā)主管和項目經(jīng)理。

國外軟件產(chǎn)業(yè)界在軟件配置管理這個專題上已經(jīng)進行了多年的理論和實踐上的研究。在多年經(jīng)驗積累的基礎上，產(chǎn)業(yè)界總結出來一系列“最佳實踐”（Best Practices），我們可以使用這些“最佳實踐”來作為評估一個組織軟件配置管理能力的標尺，也可以作為我們實施軟件配置管理的指南。這些“最佳實踐”包括：

1、標識需要進行存儲的工件（Artifact）并保障安全存儲；

2、控制并且審計（Audit）對于工件的修改；

3、設立并管理基線（Baseline）；

4、記錄并跟蹤變更請求；

5、維護穩(wěn)定、一致的工作空間；

6、支持對于工件和控件的并發(fā)修改；

7、盡早集成、持續(xù)集成；

8、保證軟件構建的重現(xiàn)能力；

9、以控件（Component）為單位實施版本控制；

10、使用“活動”（Activity）來組織和整合版本集。

下文將介紹前5條最佳實踐。

1、標識需要進行存儲的工件（Artifact）并保障安全存儲

在軟件開發(fā)過程中，我們會得到各種各樣的產(chǎn)出，比如各種文檔、模型、源代碼以及測試腳本等，我們把這些大家勞動的成果統(tǒng)稱為工件（Artifact）。對于一個軟件開發(fā)組織來說，這些工件就構成了組織的核心資產(chǎn)。對于如現(xiàn)金、有價證券之類的資產(chǎn)，我們都會準備一個保險箱，好好地保存；對于軟件資產(chǎn)，我們也需要相似的措施。所以，軟件配置管理工作的第一步就是建立一個安全、可靠的存儲庫（Repository），用于保存組織的核心軟件資產(chǎn)。這個庫對于開發(fā)團隊來說，就像是財務室里的保險箱。因此，容錯能力和高可靠性是這個庫最重要的屬性。除此之外，隨著

組織的增長，置于庫中的數(shù)據(jù)會越來越多，為保證運行效率，庫的可擴展性也是非常重要的一個屬性。

對于存儲庫來說，良好規(guī)劃的備份和災難恢復過程是必不可少的。令人驚訝的是，很多軟件組織在這方面都沒有給予必要的重視，因而也給組織的發(fā)展留下了嚴重的隱患，一旦災難發(fā)生，后果不堪設想。

在建立好存儲庫以后，需要做的工作就是確定將哪些工件置于庫中。根據(jù)實際需要，組織可能會決定只將正式文檔、模型文件、源代碼、發(fā)布版本等文件放入庫中，而對于臨時文檔、編譯時產(chǎn)生的中間文件等，則不將它們放入庫中。我們把放入庫中的文件稱之為配置項（Configuration Item）。

2、控制并且審計（Audit）對于工件的修改

在標識相關的工件并將它們置于存儲庫中以后，我們需要建立對于這些工件的修改控制機制以及審計機制。

庫里的工件不是誰想修改就可以修改的?？刂茩C制必須保證只有拿到授權的人員才能對相關工件進行修改，而審計機制則保證修改的動作被完整地記錄，也就是說，誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方（Who、When、Why、What）。審計機制通常通過“檢出/檢入”（Check out/Check in）模式得到實現(xiàn)。在這種模式下，工件一旦入庫，讀寫權限就變成只讀（read only），如果要對該工件進行修改，則需要通過“檢出”這個步驟；在修改結束以后，如果希望將修改的成果入庫，則需要通過“檢入”這個步驟。在經(jīng)過一次“檢出/檢入”步驟以后，會形成該工件新的版本，因此也有人把上邊的過程稱之為“版本控制”（Version Control）。在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、What）。

3、設立并管理基線

通過審計機制我們可以保存一個工件完整的變更歷史；但是一個項目通常是由成百上千個工件構成的，每個工件在變更過程中都會形成一系列的版本，如何確認系統(tǒng)在某個時刻分別由哪些工件的哪些版本構成？這就需要引入一個概念：配置（Configuration）。對于軟件系統(tǒng)來說，在開發(fā)過程中某個時刻存儲庫中所有工件的一個“快照”（snapshot），就形成一個“配置”。對于一些重要時刻的系統(tǒng)配置，我們可以使用基線（Baseline）來進行標志。

IEEE對于基線的定義是：已經(jīng)通過正式復審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變更控制過程進行改變

簡單地說，基線就是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于這個標準進行，并且只有經(jīng)過授權后才能變更這個標準。建立一個初始基線后，以后每次對它進行的變更都將記錄為一個差值，直到建成下一個基線。

建立基線的主要原因是：重現(xiàn)能力、可追蹤性和報告能力。

重現(xiàn)能力是指返回并重新生成軟件系統(tǒng)給定發(fā)布版本的能力?？勺粉櫺越㈨椖扛鞣N類型工件（需求、設計、實現(xiàn)、測試等）之間的橫行依賴關系，其目的在于確保設計滿足需求、代碼實施

設計以及使用正確代碼編譯生成可執(zhí)行文件。報告能力來源于一個基線內(nèi)容同另一個基線內(nèi)容的比較，基線比較有助于程序調(diào)試并生成發(fā)布說明（Release notes）。

建立基線有以下幾個好處：

(1)基線為開發(fā)工件提供了一個定點和快照。新項目可以從基線提供的定點之中建立。

(2)當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。

(3)可以利用基線重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)被報告的錯誤。在開發(fā)過程中，需要定期建立基線以確保團隊開發(fā)人員的工作保持同步，通常，在項目生命周期中的里程碑處定期建立基線。

4、記錄并跟蹤變更請求

以上我們談論的都是對于工件的變更活動的實施，下面我們要談到的是軟件配置管理的另一個方面：對于變更請求的管理。這是變更活動的源頭。

著名的軟件大師Brooks曾經(jīng)談到導致軟件開發(fā)困難的一個原因就是軟件的可變性。大家都知道，各種要素，如市場的變化、技術的進步、客戶對于項目認識的深入等等，都可能導致軟件開發(fā)過程中的變更請求的提出，而且承認這種變更請求的合理性也已經(jīng)是工業(yè)界的共識。

但是，如果缺乏對于變更請求的有效的管理能力，紛至沓來的變更就會成為開發(fā)團隊的噩夢。缺乏有效的變更請求管理會導致以下一些問題：

（1）軟件產(chǎn)品質(zhì)量低下，對一些缺陷的修正被遺漏；

（2）項目經(jīng)理不了解開發(fā)人員的工作進展，缺乏對項目現(xiàn)狀進行客觀評估的能力；

（3）開發(fā)人員不了解手頭工作的優(yōu)先級別，可能出現(xiàn)將緊急的事情放在一邊、而工作在一般優(yōu)先級任務上的情況。

變更請求管理的復雜程度與變更的具體類型有關。簡單地說，變更請求管理會涉及到變更請求的提交、變更請求的復審、變更任務分配、變更結果的驗證等一系列活動。通常，變更請求管理的流程是：由請求者提交變更請求，變更控制委員會（Change Control Board，CCB）召開CCB復審會議對變更請求進行復審，以確定該請求是否為有效請求。如果是，則基于項目團隊所確定的優(yōu)先級、時間表、資源、變更難度、風險、嚴重性以及其他相關標準，判定對該變更的修改程序，并分配實施變更任務的人力資源和時間資源；變更任務實施人員負責實施該變更；實施結束以后提交驗證人員，由驗證人員負責對變更結果進行驗證，如果變更成功則通知相關人員，否則由變更實施人員返工。

典型的變更請求管理如需求變更管理、缺陷追蹤等。實施有效的變更請求管理有以下好處：

（1）提高軟件產(chǎn)品質(zhì)量；

（2）提高開發(fā)團隊溝通效率；

（3）幫助項目管理人員對產(chǎn)品狀態(tài)進行客觀的評估。

關于變更請求管理的詳細過程以及相關準則PMT將在相關報告中闡述。

5、維護穩(wěn)定、一致的工作空間

在我們把相關工件納入集中的存儲庫、大家也都遵照“檢出/檢入”的工作模式對工件進行修改以后，下一步的工作就是要為每位開發(fā)人員設定“私有”的工作區(qū)，或者叫做工作空間。

工作空間通常以特定的基線為基礎創(chuàng)建，要求能夠做到為指定的任務方便地取出正確的工作版本建立私有工作空間；開發(fā)人員根據(jù)項目要求在自己的私有空間中對工件進行修改和測試活動，而與其他開發(fā)人員相對保持隔離，也就是說，自己的修改活動不會受到他人的影響，也不會影響到其他開發(fā)人員。但是，在保持隔離的同時，又應該提供相應的機制，當開發(fā)人員希望共享工作成果的時候，能夠很方便地實現(xiàn)共享。

開發(fā)人員日常的開發(fā)工作都是在工作空間里進行的，因此，穩(wěn)定性應該是工作空間首要的特性，只有高度穩(wěn)定的工作空間才能保證開發(fā)人員的工作效率。