配置管理培訓材料

① 配置管理的精髓

具體來講，配置管理包含如下內容： 標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，並以某種形式提供對它們的存取。 控制：通過一定的機制控制對配置項的修改。 狀態報告：記錄並報告配置項以及元數據的狀態。 配置審計：確認產品的完整性並維護配置項間的一致性。 從上面的描述知道，配置管理的基本單位是配置項。
從「哲學」意義上講，它記錄配置項的三個方面： 從哪裡來？此項可歸結為WWW的問題，（Who）誰創建的？（When）什麼時間創建的？（Why）為什麼創建此配置項？ 當前在哪裡？此項紀錄配置項當前的存儲位置以及狀態。 將到哪裡去？通過配置控制來把配置項「組裝」到正確的版本中去。 配置項可以是大粒度的，也可以是小粒度的。如果跟蹤個別需求，那麼不必要把整個需求規格說明文檔定義為一個配置項，可以把每個需求定義為配置項；如果把軟體開發工具也放入配置管理系統，那麼把配置項定義為文件級就不合適了，只需要跟蹤開發工具的版本，即把整個配置工具定義為一個配置項就足夠了。
簡而言之，配置項可以是文件級粒度的，也可以是文件版本級粒度的。當然，粒度越小管理的成本越高，但是配置的精度也就越高。
一個完整的SCM系統要具有三個核心功能：版本控制、變更控制、配置控制以及兩個支持功能：狀態統計和配置審計。 版本，亦稱配置標識，是指某一特定對象的具體實例的潛在存在。這里的某一特定對象是指版本維護工具管理的軟體組成單元，一般是指源文件；具體實例則是指軟體開發人員從軟體庫中恢復出來的某軟體組成單元的具有一定內容和屬性的一個真實拷貝。例如，對源文件的每一次修改都生成一個新版本。
版本控制就是對在軟體開發過程中所創建的配置對象的不同版本進行管理，保證任何時候都能取到正確的版本以及版本的組合。
當前，這方面典型的工具有如VSS和CVS。 變更控制是通過對變更請求（Change Request，簡稱CR）進行分類、追蹤和管理的過程來實現的。變更的起源有兩種：功能變更和缺陷修補（Bug-Fix）。功能變更是為了增加或者刪除某些功能。缺陷修補則是對已存在的缺陷進行修補。
對變更進行控制的機構稱為變更控制委員會（Change Control Board，簡稱CCB）。變更控制委員會要定期召開會議，對近期所產生的變更請求進行分析、整理，並做出決定。而且要遵循一定的變更機制。
下面是一個典型的變更機制：
可以隨著變更過程的推進，提升配置項的狀態。 這方面的工具有Bugzilla。 配置控制使用戶能夠通過對適當版本的選擇來組成特定屬性（配置）的軟體系統，這種靈活的「組裝」策略使得配置管理系統像搭積木似的使用已有的積木（版本）組裝成各種各樣、不同功能的模型。
軟體產品的每個版本都是一組配置項（源代碼、文檔、數據）的集合。配置控制就是要保證每個配置的完整性和精確性。
舉個例子來說，要發布軟體的32.6版本，那麼就要把源代碼、文檔、數據中所有應該包含到這個版本中的正確配置項檢出。
在開發過程中，在不同階段要建立各種基線。基線的建立是配置控制功能的典型應用。所以說，基線是具有里程碑意義的一個配置。
一般的商業軟體配置管理工具都具有配置控制的功能，只是靈活性和精確性有差別。 配置審計要審查以下項： 整個配置管理過程是否符合規范 配置項是否與需求一致，記錄正確 配置的組成是否具有一致性 其它 由於現在軟體行業越來越重視質量，許多項目專門成立質量保證部門專門來進行配置審計。所以現在也可以說，配置審計是一個SQA（軟體質量保證）活動。

② 配置管理的經驗

圍繞配置管理，世界一些致力於軟體工程研究的公司在深入理解ISO 9000的基礎上，推出了各種符合ISO 9000配置管理標準的工具軟體，如INTERSOLV公司的PVCS、Rational公司的Clear Case等。這些配置管理工具面向軟體規范化、工程化、自動化的需要，幫助開發團隊提高科學管理水平，從而提高工程效率，降低工程成本。現以PVCS為例，結合實際經驗，談談實施配置管理的益處： 1．縮短開發周期
利用PVCS的Version Manager對程序資源進行版本管理和跟蹤，建立公司的代碼知識庫，保存開發過程中每一過程版本，這樣大大提高了代碼的重用率，還便於同時維護多個版本和進行新版本的開發，防止系統崩潰,最大限度地共享代碼。同時項目管理人員可以通過Version Manager查看項目開發日誌，測試人員可以根據開發日誌和不同版本對軟體進行測試，工程人員可以從Version Manager上得到不同的運行版本，並且Version Manager 可以安裝在Web Server供外地施工人員存取最新版本，無需開發人員親臨現場。
利用Tracker組建開發團體之間的問題跟蹤及消息通迅，通過其Notify模塊與電子郵件結合起來大大加強了開發團體之間的溝通，Reporter模塊可對發現的問題進行整理、以報表方式分類報出，作為開發的指導。
以上為PVCS的兩個主要模塊，科學地應用可以大大提高開發效率，避免了代碼覆蓋、溝通不夠、開發無序的混亂局面，如果利用了公司原有的知識庫，則更能提高工作效率，縮短開發周期。
2 ．減少施工費用
利用PVCS進行軟體配置管理後，建立開發管理規范，把版本管理檔案掛接在公司內部的Web伺服器上，內部直接通過Netscape訪問Version Manager，工程人員通過遠程進入內部網，獲取所需的最新版本。開發人員無需下現場，現場工程人員通過對方系統管理員收集反饋意見，書面提交到公司內部開發組項目經理，開發組內部討論決定是否修改，並作出書面答復。這樣做，可以同時響應多個項目點，防止開發人員分配到各個項目點、分散力量、人員不夠的問題，同時節約大量的旅差費用。 1．代碼對象庫
軟體代碼是軟體開發人員腦力勞動的結晶，也是軟體公司的寶貴財富，長期開發過程中形成的各種代碼對象就像一個個零件坯一樣，是快速生成系統的組成部分。長期的一個事實是：一旦某個開發人員離開工作崗位，其原來所作的代碼便基本成為垃圾，無人過問。究其原因，就是沒有專門對各人的有用對象進行管理，把其使用范圍擴大到公司一級，進行規范化，加以說明和普及。Version Manager為對象管理提供了一個平台和倉庫，有利於建立公司級的代碼對象庫。
2．業務及經驗庫
通過PVCS Version Manager的注釋及Tracker，可形成完整的開發日誌及問題集合，以文字方式伴隨開發的整個過程，不依某個人的轉移而消失，有利於公司積累業務經驗，無論對版本整改或版本升級，都具有重要的指導作用。 1．量化工作量考核
傳統的開發管理中，工作量一直是難以估量的指標，靠開發人員自己把握，隨意性相當大，靠管理人員把握，主觀性又太強。採用PVCS管理後，開發人員每天下班前對修改的文件 Check In，其中記述當天修改細節描述，這些描述可以作為工作量的衡量指標。
2．規范測試
採用PVCS以後，測試有了實實在在的工作，測試工作人員根據每天的修改細節描述對每一天的工作做具體的測試，對測試人員也具有可考核性，這樣環環相扣，大大減少了其工作的隨意性。
3． 加強協調與溝通
採用PVCS後，通過Version Manager文檔共享及其特定鎖機制、Tracker與電子郵件的集成，大大加強了項目成員之間的溝通，做到有問題及時發現、及時修改、及時通知，但又不額外增加很多的工作量。

③ 求綠化養護作業人員配備及管理培訓方案 擬設立的各項管理規章制度及檔案資料的建立與管理 急

保潔公司保潔管理制度及規范
當值領班交接班制度
一、當值領班應提前10分鍾到崗，做好保潔員交接班前准備工作。
二、認真填寫交接班登記，填寫內容：
1、員工到崗情況：應到人數、實到人數、缺勤原因
臨時交辦的其他任務。
保潔領班崗位職責
一、負責監督執行公司及部門的各項規章制度。
二、負責檢查保潔員的儀容儀表和到崗情況，作好考核評估記錄。
三、根據當日工作任務，負責每日工作的分配指派。
四、負責檢查所轄范圍各責任區的清潔衛生狀況。
五、負責隨時檢查保潔員的工作狀況，及時調整各種工具及人力的配置。
六、負責對保潔員的工作態度和工作質量作出恰當的批評、糾正、指導，並作出正確的評估。
七、負責對清潔工具、設備的使用維護進行指導。
八、負責檢查設備、工具的清潔保養工作。
九、協助處理涉內外糾紛、投訴。
十、負責每日工作記錄的填寫及交接班工作。
十一、完成領導交辦的其他任務。
保潔主管職責
一、負責監督執行公司的各項規章制度，制定部門規定。
二、負責制定園區清掃管理和綠化養護管理的實施方案。
三、負責制定園區各清潔項目和綠化養護的實施執行標准。
四、負責編制人員的計劃安排。
五、負責制定消殺服務實施方案。
六、負責核實工具用品的申購計劃。
七、定期巡查園區，檢查保潔和綠化任務完成的情況。
八、對一些專用設備進行使用指導。
九、負責處理涉內外糾紛、投訴。
十、負責各種清潔、綠化業務的接洽。
十一、負責對員工進行業務培訓和考核工作。
十二、完成領導交辦的其他任務。
保潔部考勤規定
190494233

④ 配置管理的配置管理的商業模型

配置管理的實施包括兩部分：工具和規范。
在軟體開發過程自動化的今天，沒有工具的支持而實施配置完整的配置管理是不能想像的。因此選擇一個符合公司或項目的工具至關重要。在配置管理系統中，可歸納出以下四種模型。當前商業工具一般採用其中一種或幾種模型。 CICO模型 組織模型 長事務模型 變更集模型 通過對商業模型的理解，可以幫助了解某種工具是否適合某個公司或項目。 CICO模型主要關注的是單個文件的版本控制。圖顯示了一個支持CICO模型的CM系統的工作過程。用戶利用庫和文件系統來進行工作。文件被版本化並存儲到庫中，新版本的產生由庫工具控制。然而， 文件在庫中不是可以直接存取的，用戶必須去檢出（即Check out）一個文件的版本到工作空間中以便讀取它的內容。更改後的文件可以被檢入庫中（即Check in）,產生文件的一個新版本。
此模型的代表工具是SCCS和CVS。 組織模型由CICO模型自然導出，建立於構件版本圖的基礎之上，同時依賴於存儲庫和工作空間的概念，可以通過對構件加鎖進行並發控制。組織模型的重點是在CM系統支撐下加強了對創建配置、對有關的歷史信息的管理和使用他們作為工作環境的支持。
組織模型中的配置由系統模型和版本選擇規則組成。系統模型列出了組成系統的所有的構件。版本選擇規則指出了組成配置的每一個構件選擇版本。選擇規則用於系統模型，選擇構件版本，即綁定一個構件到某一版本。這個模型的操作方式是：開發人員根據模型的構件定義整個系統，並在每一步驟中給每個構件選擇合適的版本。版本操作的工作方式如圖所示。
CM支持主要關心的是維護系統和其構件的版本歷史，並選擇符合一致性配置的構件版本。只有在所選構件的版本與所選其它構件版本一致時才認為一個配置版本。
此模型的代表工具是CCC。 長事務模型主要支持包括一系列原子變更的全系統演變和由團隊開發人員對系統變更的協調。開發人員主要操作配置而非單獨的構件。事務提交的結果是新配置版本，一系列連續的變更結果生成一系列的配置版本，稱為開發路徑。
在長事務模型中，開發人員主要的工作對象是配置，開發人員首先選擇系統配置版本，接下來把關注重點放在系統結構上。構件的版本由配置隱式決定。長事務由兩個概念組成：工作空間和並發控制方案。工作空間來源於存儲庫或一個封閉工作空間中的一個固定配置。工作空間由工作配置和一系列已保存的配置組成。工作配置代表構件和系統結構能夠被動態更改的配置。提供通過工作空間進行的透明庫訪問、將高效的庫存儲技術應用於工作空間和管理派生構件的版本。
此模型的代表系統是NSE。 主要集中於對系統配置的邏輯變更的支持。在這個模型中引入的變更集表示組成邏輯變更的對不同構件修改的集合，它是創建變更的活動完成後對邏輯變更的記錄。支持這個模型的CM系統用戶可以直接操作變更集。在變更集模型中，配置可描述為由基線和一組變更集組成。
變更傳播給其它配置可通過包含各自變更集來進行。開發人員使用不同的集成策略將邏輯變更集包含到一個新的系統發行中。這樣的好處非常明顯，例如，維護10個不同版本的產品，現在要對所有的版本修改一個缺陷（Bug）。如果相同的工具簡單的重復10次顯然是不可接受的。而通過變更集把這個邏輯變更從一個版本自由的傳到另外一個版本。
開發人員可跟蹤邏輯變更和確定這些變更是否屬於特定配置。這種配置管理的方法，因為其將重點放於邏輯變更上，所以被稱作面向變更的配置管理。它不同於現在的其他3種CM模型，因為其它3種CM模型使用的面向版本的方法把重點放在構件和配置版本上。
在單一構件的情況下，變更集是兩個文件版本之間區別的集合，通常指的是增量內容。對配置來說，變更集就是兩個配置版本之間區別的集合。這組區別就是兩個配置版本間的修改構件增量集合，即變更構件集的增量。
面向變更的觀點不同於面向版本的觀點。這有兩點不同，一是邏輯變更的顯式表示允許對與單個構件和配置有關的變更集進行跟蹤。二是引用單個變更集並有選擇地將它們納入配置管理中的這種能力提供了對系統演化管理的支持，這種演化是基於將邏輯變更傳播到維護的系統配置進行的。
此模型的代表工具是UCM和SABLIME。

⑤ 配置管理的實施

實施配置管理系統，一般的步驟和需要考慮的問題如下：
1．規劃、調整網路開發環境
一個規劃良好的開發環境，是實施配置管理系統的前提。在此階段，要對配置管理系統做出規劃，主要考慮以下問題： 網路的帶寬、拓撲結構 伺服器的選擇、命名規范 存儲區的定位 開發人員及組的命名規約等 2．設計配置管理庫
根據項目開發的要求，設計開發資源的存儲模式，良好的存儲模式有利於減輕管理上的負擔，增強配置管理庫的訪問性能，同時便於控制訪問許可權，保護軟體資產。
3．定義配置管理系統的角色
在此階段，需要確定與配置管理相關的所有角色，包括他所有角色相應的活動。在開發過程中，一個開發人員可能兼任多種角色，但一項任務在同一時刻只能由一個角色來執行。
一般配置管理中的角色主要包括： 項目經理：項目經理在配置管理方面的職責是依靠配置管理員、系統管理員和系統體系結構設計人員的幫助，制定項目的組織結構和配置管理策略。這些工作包括：定製開發子系統，定製訪問控制，制定常用策略，制定集成里程碑，以及進行系統集成。 配置管理員：配置管理員的職責是根據項目經理制定的開發組織結構和策略，實施、維護配置管理的環境。其主要職責如下：創建配置管理庫，對存儲庫進行日常備份和恢復，維護配置管理環境，及管理配置管理相關的用戶。 軟體開發人員：軟體開發人員依據項目的開發和配置管理策略，創建、修改和測試開發工件。 集成人員：對軟體進行歸並，形成相應的基線或發布版本。 QA人員：需要對軟體配置管理有較深的認識，其主要工作是跟蹤當前項目的狀態，測試，報告錯誤，並驗證其修復結果。 4．制定配置管理流程
這是配置管理實施的一個重要階段，其主要目的是根據項目開發的需要，制定相應的配置管理流程，以更好地支持開發，主要活動包括： 定製並行開發策略：合理的並行開發策略應該具有以下特點：協調項目的復雜性和需求，統一創建分支類型和元數據，為開發過程中的變更集成制定有效的規范，適時反映開發過程中方法和需求的變化。 發布版本管理：軟體開發過程中的一個關鍵活動是提取工件的相關版本，以形成軟體系統的階段版本或發布版本，我們一般將其稱為穩定基線。一個穩定基線代表新開發活動的開始，而一系列定製良好的活動之後又會產生一個新的穩定基線。有效地利用此項功能，在項目開發過程中可以自始至終管理、跟蹤工件版本間的關聯。 一般來講，實施配置管理系統，相關人員需要接受以下培訓： 管理員培訓：針對配置管理員，主要學習配置管理工具管理相關內容。 開發人員培訓：針對開發人員，主要學習配置管理工具與開發相關的常用操作。 管理流程培訓：針對全體人員，目的是了解配置管理策略和流程，以及如何與開發管理、項目管理相結合。

⑥ 軟體配置管理培訓課程需求！

「中國電子標准協會WAYS」有專業的2-3天「軟體項目配置管理及工具操作實踐「的課程。詳情你可以網路一下他們協會到他們網站上看看。以下為相關課程的課程大綱：

1、軟體工程&配置管理概述
o 軟體工程與質量管理簡介
o 配置管理在質量管理、軟體工程中的作用意義
o 配置管理發展歷史
o 引入配置管理的原因
o 配置管理的作用意義
o 各方法論/模型中配置管理
2、配置管理概念與術語
o 軟體配置管理
o 配置項
o 基線
o 版本
o 配置狀態報告
o 配置審計
o 配置管理員
o 配置控制委員會
o 配置庫
o 出/入庫
3、CMMI中CM過程
o CMMI2過程域簡介
o CM通用實踐要求
o CM目的
o CM特定目標
o CM特定實踐
o CM語境圖
o CM現狀分析
分組討論：結合你的工作實踐，談談你對軟體配置管理的認識，分析CMMI中CM過程應用現狀和「天生不足」
4、研發配置活動
o 研發配置框架
o 研發常見模式
o 出入庫
o 集成管理
o 分支
o 構建管理
概念流程
構建問題管理
構建環境
構建案例
交流討論：建立合適的構建制度。
o 發布管理
產品的發行與更新發布
o 版本管理
o 基線管理
o 配置變更
項目變更控制
產品變更控制
練習作業：請您設計您所在項目的研發配置活動，並說明每個配置活動的目的是什麼。
5、項目配置管理
o 配置申請/計劃
o 配置項識別
o 練習1：定義《公司級配置管理過程》
配置管理角色及職責
配置庫結構
配置庫建立及許可權管理
o 練習2：完成一份《配置管理計劃》
估計配置管理工作量
估計配置管理資源需求
配置審計與備份
協調配置管理活動與其他項目活動
o 練習3：設計一種類型項目的《配置庫結構》
o 配置基線及其項目運用
o 配置管理報告四種最佳實踐
o 配置管理文檔
案例分析：配置管理文檔實例展示分析
分組討論：配置管理與研發生命周期的關系，在研發項目各階段要嚴格控制的配置活動包括哪些？
6、公司級配置管理
集中問題討論：
o 項目啟動時怎樣定義配置管理？
o 集中式與分布式配置管理分析？
o 怎樣建立公司級的配置管理？
o 合理定製配置管理工具支持策略？
o 配置經理、配置工程師、軟體開發工程師、軟體測試人員的配置工作職責及相關協調？
o 誰是CCB？所有的變更都需要CCS審批嗎？
o 配置審核和QA審核在實際操作上的區別？
o 怎樣衡量配置管理是否有效？
o 配置管理員可以兼職嗎？誰兼職合適？
o 什麼是基線？基線和里程碑有什麼關系？基線在產品管理中的作用意義？
7、配置管理案例分析
o案例1：公司級配置管理案例分析
o簡述：JN公司是CMMI5級公司，公司建立了配置管理流程，各個部門也有一套配置管理方法，因各部門配置工具、配置庫結構、方法、團隊不相同。項目資產跨部門使用非常困難，研發人員跨部門調用比較困難，項目研發與產品研發的配置管理難以統一。
o配置策略：
配置管理現狀分析
配置目標意義
配置庫結構定義
配置工具選擇
配置流程職責
配置團隊建設
知識庫與配置管理
o 風險分析及實施步驟
建立研發配置管理子體系
研發配置管理策劃
搭建研發配置平台
選擇配置管理工具
建設配置監控隊伍
o案例2：部門配置管理案例分析
o簡述：MZ研發部，有20個項目，研發人員30人左右，其中有兩個項目實施有10年，七期項目都已經啟動，有的項目在客戶現場，有的項目在研發基地。近五年來，除開大項目經理沒有離職，其它項目經理、研發人員已經更換多次。歷史的項目資料，有的丟失，有的無人識別，發布到客戶現場的系統經常莫名其妙出錯。
o配置策略：配置庫的整合與研發配置的控制管理。
8、配置工具(SVN/VSS)項目演練
SVN 操作實踐演示
VSS 操作實踐演示（李R）
案例分析：ST研發項目配置演練

參考資料：中國電子標准協會WAYS

⑦ 配置管理技術是什麼

什麼是配置管理

在軟體開發中，變更是不可避免的。從某種角度上講，軟體開發過程就是一個變更的過程。有些變更是有益的，是具有創造性的，但是，也有些變更是有害的，導致混亂的。正像James Bach總結的那樣：

我們為變更所困擾，因為代碼中的一個極小的混亂可能帶來產品的大的故障，但是，他也能夠修復大的故障或啟用奇妙的新能力。我們為變更所困擾，因為某個喜歡惡作劇的單個開發者可能破壞掉項目，但是，一些奇妙的思想也源自那些喜歡惡作劇的人員。

因此，如何管理這些變更是一個軟體開發能否成功的關鍵。簡言之，軟體配置管理就是管理變更的過程，它貫穿著幾乎軟體的整個生命周期。成功的配置管理系統可以最大限度的減少對個別「英雄」式人員的依賴。

軟體開發過程的輸出信息可以分為三個主要的類型：

1 計算機程序（源代碼、中間代碼和可執行程序）
2 描述計算機程序的文檔（針對技術開發者和用戶）
3 數據（包含在程序內部或在程序的外部）。

這些項包含了所有的在軟體過程中產生的信息，總稱為軟體配置。該集合中每一個元素稱為該軟體產品軟體配置中的一個配置項（CI, Configuration Item）。

盡管配置管理（Configuration Management ）這個概念被提出有幾十年了，但是，業內還沒有一個全面而權威的定義。

具體地說：

配置管理是標識和控制配置項，以維護其完整性、可追溯性以及正確性的學科。

具體來講，配置管理包含如下內容：

標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，並以某種形式提供對它們的存取。

控制：通過一定的機制控制對配置項的修改

狀態報告：記錄並報告配置項以及元數據的狀態。

配置審計：確認產品的完整性並維護配置項間的一致性。

從上面的描述，我們知道，配置管理的基本單位是配置項。

從「哲學」意義上講，它記錄配置項的三個方面：

從哪裡來？此項可歸結為WWW的問題，（Who）誰創建的？（When）什麼時間創建的？（Why）為什麼創建此配置項？

當前在哪裡？此項紀錄配置項當前的存儲位置以及狀態。

將到哪裡去？通過配置控制來把配置項「組裝」到正確的版本中去。

配置項可以是大粒度的，也可以是小粒度的。如果跟蹤個別需求，那麼不必要把整個需求規格說明文檔定義為一個配置項，可以把每個需求定義為配置項；如果把軟體開發工具也放入配置管理系統，那麼把配置項定義為文件級就不合適了，只需要跟蹤開發工具的版本，即把整個配置工具定義為一個配置項就足夠了。

簡而言之，配置項可以是文件級粒度的，也可以使文件版本級粒度的。當然，粒度越小管理的成本越高，但是配置的精度也就越高。

一個完整的SCM系統要具有三個核心功能：版本控制、變更控制、配置控制以及兩個支持功能：狀態統計和配置審計。

⑧ 誰知道軟體「配置管理庫」的概念，請解說一下，或者給個資料。

網上有很多這樣的資料咯，對三個配置庫的定義我附了一張圖片不知道你能不能看到

配置管理是指：應用技術和管理手段來識別和記錄配置項的功能和物理特性，控制其變更，記錄和報告變更的過程和實現狀態，並檢查與項目需求之間的符合度；通過配置管理可以有效的管理工作產品與工作產品之間的一致性，合理的控制和實施變更以維護對項目范圍與邊界條件的一致的理解。

本過程描述了配置管理活動的內容、規范和方法，以建立和維護軟體開發過程中各種產品的完整性和一致性。

本過程中將使用到以下幾個重要的術語：

配置項：處於配置管理之下的軟體或/和硬體的集合體。這個集合體在配置管理過程中作為一個實體出現。

基線：已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，並且只能通過正式變更控制過程來改變；基線有一組配置組成，這些配置構成了一個相對穩定的狀態，不能再被任何人隨意修改。

配置標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，並以某種形式提供對它們的存取。

控制：通過建立產品基線，控制軟體產品的發布和在整個軟體生命周期中對軟體產品的修改。

狀態統計：記錄並報告構件和修改請求的狀態，並收集關於產品構件的重要統計信息。

配置審計：通過第三方（例如：軟體質量保證工程師）來確認產品的完整性並維護構件間的一致性，即確保產品是一個嚴格定義的構件集合；

配置管理員：根據過程的規定，在公司內部具體實施與操作本過程的人員/角色。根據實施的層級的不同，配置管理員可以區分為「產品配置管理員」和「項目配置管理員」兩個角色，一般產品配置管理員是專職的，項目配置管理員有項目成員兼職。

⑨ 配置管理的簡介

配置管理過程是對處於不斷演化、完善過程中的軟體產品的管理過程。一致性、可追溯性，使產品極大程度地與用戶需求相吻合。它通過控制、記錄、追蹤對軟體的修改和每個修改生成的軟體組成部件來實現對軟體產品的管理功能。
早在七十年代初期加利福利亞大學的Leon Presser教授就撰寫了一篇論文，提出控制變更和配置的概念，之後在1975年，他成立了一家名為SoftTool的公司，開發了自己的配置管理工具：CCC，這也是最早的配置管理工具之一。之後，隨著軟體開發規模的逐漸增大，越來越多的公司和團隊意識到了軟體配置管理的重要性，而相應的軟體配置管理工具也如雨後春筍一般，紛紛涌現，比較有代表性的有：Marc Rochkind的SCCS（Source Code Control System）和Walter Tichy的RCS（Revision Control System），這兩種工具對日後的配置管理工具的發展做出了重大的貢獻，目前絕大多數廣泛使用的配置管理工具基本上都是基於這兩者的設計思想和體系架構。
配置管理在軟體開發過程和項目管理過程中的作用
隨著軟體系統的日益復雜化和用戶需求、軟體更新的頻繁化，配置管理逐漸成為軟體生命周期中的重要控制過程，在軟體開發過程中扮演著越來越來重要的角色。一個好的配置管理過程能覆蓋軟體開發和維護的各個方面，同時對軟體開發過程的宏觀管理，即項目管理，也有重要的支持作用。良好的配置管理能使軟體開發過程有更好的可預測性，使軟體系統具有可重復性，使用戶和主管部門用軟體質量和開發小組有更強的信心。
軟體配置管理的最終目標是管理軟體產品。由於軟體產品是在用戶不斷變化的需求驅動下不斷變化，為了保證對產品有效地進行控制和追蹤，配置管理過程不能僅僅對靜態的、成形的產品進行管理，而必須對動態的、成長的產品進行管理。由此可見，配置管理同軟體開發過程緊密相關。配置管理必須緊扣軟體開發過程的各個環節：管理用戶所提出的需求，監控其實施，確保用戶需求最終落實到產品的各個版本中去，並在產品發行和用戶支持等方面提供幫助，響應用戶新的需求，推動新的開發周期。通過配置管理過程的控制，用戶對軟體產品的需求如同普通產品的訂單一樣，遵循一個嚴格的流程，經過一條受控的生產流水線，最後形成產品，發售給相應用戶。從另一個角度看，在產品開發的不同階段通常有不同的任務，由不同的角色擔當，各個角色職責明確，涇渭分明，但同時又前後銜接，相互協調。
好的配置管理過程有助於規范各個角色的行為，同時又為角色之間的任務傳遞提供無縫的接合，使整個開發團隊像是一個交響樂隊一樣和諧而又錯雜地行進。正因為配置管理過程直接連接產品開發過程、開發人員和最終產品，這些都是項目主管人員所關注的重點，因此配置管理系統在軟體項目管理中也起著重要作用。配置管理過程演化出的控制、報告功能可幫助項目經理更好地了解項目的進度、開發人員的負荷、工作效率和產品質量狀況、交付日期等信息。同時配置管理過程所規范的工作流程和明確的分工有利於管理者應付開發人員流動的困境，使新的成員可以快速實現任務交接，盡量減少因人員流動而造成的損失。