1. 為了系統地控制配置變更，在系統的整個生命周期中維持配置的完整性和可跟蹤性，而標識系統在不同時間點上配置的學科

2. 配置項

2.1. 為配置管理設計的硬件、軟件或二者的集合，在配置管理過程中作為一個單個實體來對待

3. 基線配置項

3.1. 基線配置項向開發人員開放讀取的權限

4. 非基線配置項

4.1. 非基線配置項向PM、CCB及相關人員開放

5. 配置項狀態

5.1. 草稿

5.1.1. 配置項剛建立時

5.2. 正式

5.2.1. 配置項通過評審后

5.2.2. 當配置項修改完畢并重新通過評審時

5.3. 修改

5.3.1. 此后若更改配置項

6. 配置項版本號

6.1. 草稿

6.1.1. 格式為O.YZ,

6.1.1.1. 【22上選60】

6.1.2. YZ的數字范圍為01?99

6.2. 正式

6.2.1. 格式為X.Y

6.2.2. X為主版本號

6.2.2.1. 【21上選60】

6.2.2.2. 取值范圍為1?9

6.2.3. Y為次版本號

6.2.3.1. 取值范圍為0?9

6.3. 修改

6.3.1. 【20下選60】

6.3.1.1. 【19下選60】

6.3.2. 格式為X.YZ

7. 版本管理

7.1. 按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，并且可以快速準確地查找到配置項的任何版本

7.2. 不能保證新版本一定比舊版本“好”，所以不能拋棄舊版本

8. 配置基線（Configuration Baseline）

8.1. 對應于開發過程中的里程碑（Milestone）

8.2. 常簡稱為基線

8.3. 由一組配置項組成，這些配置項構成一個相對穩定的邏輯實體

8.4. 發行基線（Release Baseline）

8.5. 構造基線（Build Baseline）

8.6. 好處

8.6.1. 為開發工作提供了一個定點和快照

8.6.2. 新項目作為一個單獨分支，將與隨后對原始項目（在主要分支上）所進行的變更進行隔離

8.6.3. 當認為更新不穩定或不可信時，基線為團隊提供一種取消變更的方法

8.6.4. 可以利用基線重新建立基于某個特定發布版本的配置，以重現已報告的錯誤

9. 配置庫（Configuration Library）

9.1. 開發庫(Development Library)

9.1.1. 【22下選60】

9.1.2. 動態庫、程序員庫或工作庫

9.1.3. 用于保存開發人員當前正在開發的配置實體

9.1.3.1. 【19上選62】

9.2. 受控庫(Controlled Library）

9.2.1. 主庫

9.2.2. 包含當前的基線加上對基線的變更

9.3. 產品庫(Product Library

9.3.1. 靜態庫、發行庫、軟件倉庫

9.3.2. 包含己發布使用的各種基線的存檔

9.3.3. 拉出一個SS分支修復嚴重問題并發布最終軟件，關鍵詞是“發布最終軟件”，說明軟件最終是在SS分支上發布的，更匹配產品庫的概念

9.3.3.1. 【22下選59】

9.4. 建庫模式

9.4.1. 按配置項類型建庫

9.4.1.1. 適用于通用軟件的開發組織

9.4.2. 按任務建庫

9.4.2.1. 適用于專業軟件的開發組織

9.5.

9.5.1. 【21下選60】

9.6. 將副本存儲在不同的受控場所,以減少丟失的風險

9.6.1. 【21上選61】

10. 權限設置

10.1. r

10.2. c

10.3. a

10.4. d

11. 配置控制委員會(Configuration Control Board, CCB）

11.1. 負責對配置變更做出評估、審批以及監督已批準變更的實施

11.2. 項目級

11.3. 不必是常設機構

12. 配置管理員(Configuration Management Officer, CMO）

12.1. 編寫配置管理計劃

12.2. 建立和維護配置管理系統

12.3. 建立和維護配置庫

12.4. 配置項識別

12.5. 建立和管理基線

12.6. 版本管理和配置控制

12.7. 配置狀態報告

12.8. 配置審計

12.9. 發布管理和交付

12.10. 對項目成員進行配置管理培訓

13. 配置管理系統

13.1. 用來進行配置管理的軟件系統

14. 6個主要活動

14.1. 制定配置管理計劃

14.2. 配置標識(Configuration Identification)

14.2.1. 配置識別

14.3. 配置控制

14.3.1. 配置項和基線的變更控制

14.3.2. 變更申請

14.3.2.1. 要做什么變更，為什么要做，以及打算怎么做變更

14.3.3. 變更評估

14.3.3.1. CCB負責組織對變更申請進行評估

14.3.4. 通告評估結果

14.3.4.1. CCB把關于每個變更申請的批準、否決或推遲的決定通知受此處置意見影響的每個干系人

14.3.5. 變更實施

14.3.6. 變更驗證與確認

14.3.6.1. 項目經理指定人員對變更后的配置項進行測試或驗證

14.3.7. 變更的發布

14.3.8. 基于配置庫的變更控制

14.4. 配置狀態報告(Configuration Status Reporting)

14.4.1. 配置狀態統計(Configuration Status Accounting）

14.4.2. 其任務是有效地記錄和報告管理配置所需要的信息，目的是及時、準確地給出配置項的當前狀況，供相關人員了解，以加強配置管理工作

14.5. 配置審計(Configuration Audit)

14.5.1. 配置審核或配置評價

14.5.2. 為了確保項目配置管理的有效性，體現了配置管理的最根本要求——不允許出現任何混亂現象

14.5.2.1. 【21下選61】

14.5.3. 功能配置審計（Functional Configuration Audit）

14.5.3.1. 【22上選61】

14.5.3.2. 審計配置項的一致性（配置項的實際功效是否與其需求一致）

14.5.3.3. 配置項的開發已圓滿完成

14.5.3.4. 配置項已達到配置標識中規定的性能和功能特征

14.5.3.5. 配置項的操作和支持文檔已完成并且是符合要求的

14.5.4. 物理配置審計（Physical Configuration Audit）

14.5.4.1. 審計配置項的完整性（配置項的物理存在是否與預期一致）

14.5.4.2. 要交付的配置項是否存在

14.5.4.3. 配置項中是否包含了所有必需的項目

14.6. 發布管理和交付

14.6.1. 【20下選61】

14.6.1.1. 【19下選61】

14.6.2. 存儲

14.6.3. 復制

14.6.4. 打包

14.6.5. 交付

14.6.6. 重建