第一章
1，軟件配置管理用於控制變化
2，軟件配置管理(Software Configuration Management, SCM)是指一套管理軟件開發和維護過程中所產生的各種中間軟件產品的方法和規則，它是控制軟件系統演變的學科。
3，軟件配置管理是一種標識、組織和控制修改的技術，軟件配置管理應用於整個軟件工程過程
4，SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現並向其他有關人員報告變更
5，從某種角度講，SCM的目的是使錯誤降為最小並最有效地提高生產效率。
6，軟件配置管理定義：
軟件配置管理是貫穿於整個軟件過程中的保護性活動，它被設計用來：
(1) 標識變化；(2) 控制變化；(3) 保證變化被適當的發現；(4) 向其他可能有興趣的人員報告變化
7，配置管理是否有成效取決於三個要素：人、規范、工具。
8，軟件配置是一個軟件產品在生存期各個階段的不同形式（記錄特定信息的不同媒體）和不同版本的程序、文檔及相關數據的集合，或者說是配置項的集合
9，軟件配置是一個集合，該集合中的每一個元素稱為該軟件產品軟件配置中的一個配置項（Software Configuration Item，SCI）。
10，常見的軟件配置項：需求規格說明書、設計規格說明書、源代碼、測試計划、測試用例、用戶手冊等
11，基線(Baseline)是指一個（或一組）配置項在項目生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態。基線是軟件生命周期中各開發階段的一個特定點，它的作用是把開發各階段工作的划分更加明確化，使本來連續的工作在這些點上斷開，以便於檢查與肯定階段成果
12，基線是已經正式通過復審和批准的某規約和產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程來改變。基線通常標志開發過程一個階段的結束（里程碑）。
13，里程碑(Milestone)是檢查點 (Check Point)，檢查點不一定是里程碑，因為檢查點還可以是時間、計划和事件
14，功能基線：所規定的對待開發軟件系統的規格說明
15，指派基線：又稱為分配基線，指在軟件需求分析階段結束時，經過正式評審和批准的軟件需求的規格說明，指派基線是最初批准的指派配置標識。
16，產品基線：指在軟件組裝與系統測試階段結束時，經過正式評審的批准的有關所開發的軟件產品的全部配置項的規格說明，產品基線是最初批准的產品配置標識
17，軟件配置控制委員會(Software Configuration Control Board, SCCB)負責管理軟件配置項變更的組織。
具體責任如下：
評估變更；批准變更請求；在生命周期內規范變更申請流程；對變更進行反饋；與項目管理層溝通
18，軟件配置管理是在貫穿整個軟件生命周期中建立和維護項目產品的完整性。它的基本目標包括：
-
目標 1: 軟件配置管理的各項工作是有計划進行的。
-
目標 2: 被選擇的項目產品得到識別，控制並且可以被相關人員獲取。
-
目標 3: 已識別出的項目產品的更改得到控制。
-
目標 4: 使相關組別和個人及時了解軟件基准的狀態和內容。
第二章
1，軟件配置管理角色
PM: 項目經理；CCB: 配置控制委員會；CMO: 配置管理員；SIO: 系統集成員；DEV: 開發人員
2，項目經理（Project Manager，PM）
根據軟件配置控制委員會的建議批准配置管理的各項活動並控制它們的進程。
職責：制定和修改項目的組織結構和配置管理策略；批准、發布配置管理計划；
決定項目起始基線和開發里程碑；接受並審閱配置控制委員會的報告。
配置控制委員會（Configuration Control Board，CCB）
負責指導和控制配置管理的各項具體活動的進行，為項目經理的決策提供建議。
職責：定制開發子系統；定制訪問控制；制定常用策略；建立、更改基線的設置，審核變更申請；根據配置管理員的報告決定相應的對策。
配置管理員（Configuration Management Officer，CMO）
根據配置管理計划執行各項管理任務，定期向CCB提交報告並列席CCB的例會。
職責：軟件配置管理工具的日常管理與維護；提交配置管理計划；各配置項的管理與維護；執行版本控制和變更控制方案；完成配置審計並提交報告；對開發人員進行相關的培訓；識別軟件開發過程中存在的問題並擬定解決方案。
系統集成員（System Integration Officer，SIO）
系統集成員負責生成和管理項目的內部和外部發布版本。
職責：集成修改；構建系統；完成對版本的日常維護；建立外部發布版本。
開發人員（Developer，DEV）
開發人員的職責就是根據組織內確定的軟件配置管理計划和相關規定，按照軟件配置管理工具的使用模型來完成開發任務。
3
4，軟件配置管理過程包括7項基本活動：
(1) 制定配置管理計划；(2) 識別和標志配置項；(3) 搭建配置管理環境；(4) 配置項的版本控制；(5) 基線變更管理；(6) 配置審核；(7) 配置狀態統計
5，制定配置管理計划
-
配置管理計划的主要內容：
配置管理組織及其職責；配置管理工具和配置庫的組織結構；配置項標志和基線定義；
變更管理流程；配置審核和配置狀態統計
6，識別和標志配置項：
（1）為每一個配置項分配唯一的標志；建立配置項間的對應關系
（2）兩類配置項：
-
基本配置項：軟件開發者在項目開發過程中所創建的基本工作單元。
-
集成配置項：一個集成配置項是基本配置項或其它集成配置項的集合。
7，搭建配置管理環境
配置管理環境是用於進行軟件配置管理的系統環境，其中最重要的是配置管理庫，簡稱配置庫
配置庫存儲配置項 (SCI)、修改請求、變化記錄等，並提供對庫中所存儲文件的版本控制
一般需采用配置管理工具來建立配置庫。
8，配置項的版本控制
-
配置庫的檢入檢出和版本控制機制解決了軟件開發中的兩個重要問題：
-
訪問控制：保證具有相應權限的人員才能修改配置項。
-
並行控制：保證不同人員同時對某配置項進行的修改不會互相覆蓋。
-
-
對配置項的修改（不同版本間的差別）應被記錄下來。
更動者（姓名及其身份）；更動日期和時間；被更動SCI（名及其版本號）；
更動內容及其位置；更動原因；受此更動影響的諸SCI名表。
-
軟件產品版本編號方法
-
數字順序型版本編號
普通版本編號
-
x.y.z，x為主版本號，y為特征版本號，z為缺陷修復版本號，如V3.10.16。
-
主版本號的增加表示提供給客戶的主要產品功能的增強。
-
特征版本號的增加表示產品新增了一些特征或做了一些重要修改。
-
缺陷修復版本號的增加表示在軟件產品上做了一些缺陷修復工作。
α和β版本編號
-
在普通版本編號后面增加一個大寫字符A或者B來分別表示α版本或β版本。例如1.2.4A或1.2.4B。
-
如果存在多次的α發布和β發布，可在A或B后面添加一個數字來說明發布的次數，例如：1.2.5A1，1.3.0B2。
α測試是由公司內部的用戶在模擬實際操作環境下進行的測試。
β測試是由軟件的多個用戶在實際使用環境下進行的測試。
-
屬性版本編號：
把版本的重要屬性反映在標識中。可以包括的屬性有：客戶名、開發語言、開發狀態、硬件平台、生成日期等。例如： J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
-
包含的信息豐富，方便了查詢和管理，版本間的關系易於保持，但由於太復雜，一般只用於軟件組織內部的管理
-
-
9，基線變更管理
-
變更批准或拒絕
根據評估結果對變更作出決策：
直接實現變更；掛起或延遲變更；拒絕變更
對於批准的變更，要確定其實現進度：
立即實現變更；在特定的日期實現變更；在軟件另外的版本中實現
-
變更實現
10，配置審核
配置管理活動審核：確保所有配置管理活動符合已批准的軟件配置管理規程
基線審核：審核基線配置項的完整性和一致性，從而保證基線配置項可被正確地構造。
11，配置狀態統計和報告
變更請求的數量。變更管理活動的執行情況。
配置管理系統存儲量的變化。配置管理系統和SCCB在運作中發生異常的次數
第三章
1，CMM/CMMI將軟件配置管理的活動分為6個方面，每個方面又再進行了細分
SCM過程管理；軟件配置標識；軟件配置控制；軟件配置狀態統計；軟件配置審計；軟件發布管理和交付
2，在CMM和CMMI中，將配置管理的目的定義為"建立和維護產品的完整性"，
3，配置完整性（對標准的理解）
-
產品完整性：項目提交的工作成果是"產品集合完整、子產品正確"的
-
產品集合完整：產品包含的子產品（配置項）是完整的
-
子產品正確：子產品（配置項）達到了需求要求，滿足標准、規程的要求
4，三庫管理：三庫的概念源自CMM/CMMI，即開發庫、受控庫和產品庫。配置項在三庫之間遷移，一級比一級的控制更嚴格。
5，軟件開發組日常的工作在開發庫中開展，當工作達到里程碑時，再遷移到受控庫，在受控庫中經過更嚴格的測試后，再上升到產品庫，最后發布。
6，在實踐中，三庫常常被實現為物理上的三庫，而不是通過邏輯的方式來實現，三庫物理隔離帶來的最大問題是配置項失去了歷史可追溯性
7，實現三庫的指導思想應該是邏輯上獨立，物理上在一起，通過權限與流程的控制來實現配置項在不同庫之間的流轉，以及相應角色的人員對相應庫的訪問。
-
CMM2在配置管理方面主要針對於實現部分;CMM3將配置管理擴展到需求、規格說明、設計和工具
-
SCM意義：
記錄軟件產品的演化過程；
確保軟件開發者在軟件生命周期中的各個階段都能得到精確的產品配置；
最終保證軟件產品的完整性、一致性、追朔性、可控性;。
10，每個基線都將接受配置管理的嚴格控制，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線，這就是"基線管理"的過程
11，建立基線的好處：重現性；可追蹤性；版本隔離。
基線管理的步驟：
(1) 在開發前確定基線的"配置"；(2) 基線批准前，根據"配置"檢查配置項是否齊備；
(3) 對各個配置項，確認其版本的正確性；(4) 對每個配置項建立基線標志；
(5) 基線變更管理；(6) 基線的各類報告和審計信息。
12，變更管理的流程：
（獲得）提出變更請求；由CCB審核並決定是否批准；
為（被接受）修改請求分配人員，提取SCI，進行修改；
提交修改后的SCI，並測試（或者評審）；重建軟件的適當版本；
復審（審計）所有SCI的變化；發布新版本。
---可以通過兩種表格來幫助發現受到變更影響的內容，一種是《需求跟蹤表》，一種是《配置項依賴關系表》
13，配置庫管理
(1)設置配置庫（即文件夾設置）和設置版本的分支
(2)為每個配置項從建立開始就划分成3個不同的分支：私有分支、集成分支、公共（主干）分支
私有分支（開發人員的私有開發空間）：開發人員
集成分支（開發團隊的公共空間）：由系統集成員及相關指定人員負責：所有涉及多人協調的開發工作（如集成測試等）都必須工作在這一空間中。該開發團隊擁有對該集成分支的讀寫權限，而其他成員只有只讀權限。
公共（主干）分支（整個軟件開發組織的公共空間）:系統集成員:各個開發小組在現階段的任務完成后，將可以發布的版本歸並到該分支上,對組織內的全體軟件人員開放只讀權限
上面定義的3類工作空間（分支）由配置管理員統一管理
(3)按配置項類型分類建庫和按任務建庫。
(4)配置庫的日常工作：對配置庫的定期備份；清除無用的文件和版本；檢測並改進配置庫的性能等
14,配置審計：主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現
記錄了誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方。 （Who、When、Why、What）
-
同時配置審計工作該應當說明如下信息：
(1) 變更要求被完成，並且對附加的修改已經執行了 (2) 采用了正確的正式驗證手段
(3) 遵循了標准的要求 (4) 變更的4W信息被完整記錄，並和相關配置項關聯
-
配置審計有兩種:
-
PCA (Physics Configuration Audit)-----非配置管理人員
主要是檢查版本是否正確一致。(1) 配置項是否齊備；(2) 版本是否齊全，由非配置管理人員來進行。
-
FCA (Function Configuration Audit) -----CMO
檢查配置項是否完整，各種過程文檔是否齊備、正確、與需求是否一致，歸結為兩點，即完全和齊備。
15，配置審計
-
When：軟件交付或release時；每個階段結束時；對於維護性項目，周期性地進行
-
Who：非本項目組成員；其他項目中的配置控制者；內部審計者；SCM小組
-
配置審計步驟（How-審計流程）
-
(1) 由項目經理決定何時進行配置審計工作（識別配置審計的時間[PM]）
-
(2) 質量保證組或項目組的配置管理組制定該項目的配置審計人員（指派審計者[QA/Audit Group]）
-
(3) 項目經理和配置審計員決定審計范圍（定義審計范圍[PM&Auditors]）
-
(4) 配置審計員准備配置審計檢查單（准備配置審計Checklist[Auditor]）
-
(5) 配置審計員安排時間審計文檔和記錄，審計活動可能涉及到：項目范圍，配置項的入庫(check in)及出庫(check out)，評審記錄，配置項的變更歷史，測試記錄，文件的命名，變更請求和版本的編號等
（通過評審（Review）、文檔記錄進行審計[Auditor]）
-
(6) 配置審計員在審計中發現不一致現象，並作記錄（識別不符合項[Auditor]）
-
(7) 由項目經理負責消除不一致現象（關閉不符合項[PM]）
-
(8) 配置審計員驗證所有發現的不一致現象確已得到解決（驗證[Auditor]）
16，配置狀態報告就是根據配置項操作的記錄來向管理者報告軟件開發活動的進展情況
應該是定期進行，並盡量通過CASE工具自動生成，用數據庫中的客觀數據來真實的反映各配置項的情況。
應着重反映當前基線配置項的狀態，以作為對開發進度報告的參照
17，軟件配置管理最佳實踐：
統一標識配置項並存入安全的配置管理系統；控制和審計配置項的變更；合理組織配置項；
在項目的里程碑建立相應的基線；記錄和跟蹤變更請求；過程驅動的軟件配置管理；
維護穩定而一致的工作空間；支持並行開發；盡早和持續集成；
確保有能力重現軟件的構建過程；把握好工具、流程和人員三者之間的關系；善用模式和反模式；
18，模式可以指導我們如何成功應用前人的實踐，避免犯前人犯過的錯誤，提高SCM的實施成功率。
反模式是指那些在特定情況下不應該采取的策略和方式。
第4章
1，軟件配置管理計划： 人員及職責；配置管理軟硬件資源；配置項計划；基線計划；配置庫備份計划
2，配置庫管理報告： 基本信息；項目成員的操作權限；配置項記錄；基線記錄；配置庫備份記錄；配置項交付記錄；配置庫重要操作日志
3，配置項變更控制報告： 變更申請；審批變更申請；變更配置項；結束變更
4，配置狀態報告 (Configuration Status Report)目的：有效記錄和報告管理配置所需要的信息，及時、准確地給出軟件配置項的當前狀態，供相關人員了解，以加強配置管理工作
-
內容
-
各份變更請示概要：變更請求號、日期、申請人、狀態、估計工作量、實際工作量、發行版本、變更結束日期
-
基線庫狀態：庫標識、至某日預計庫內配置項數、實際配置項數
-
發行信息：發行版本、計划發行時間、實際發行日期、說明
-
備份信息：備份日期、介質、備份存放位置
-
配置管理工具狀態
-
配置管理培訓狀態
-
5，配置審計目的：驗證配置項信息與配置標識（需求、標准、流程…）的一致性，4"W"
配置審計報告內容：配置項狀態統計；基線庫基線統計；變更統計；審計中發現的主要問題
第5章
1，配置管理模式分類： 描述工作區結構的模式； 描述碼線結構的模式
2，碼線(codeline)--源代碼文件與組成某個軟件組件的其他人工制品（配置項）隨着時間而變更的進展過程。
碼線包含沿着一條路徑發展的各個配置項的每個版本
3，與碼線有關的模式：主線； 活動開發線； 碼線策略； 私用版本； 版本線； 版本預備線； 任務分支4，與工作區有關的模式： 私有工作區；儲存庫； 私有系統構造； 集成構造； 第三方碼線；任務級提； 冒煙測試； 單元測試； 回歸測試
-
主線——問題： 如何使當前活動碼線的數目保持在容易管理的水平，避免項目的版本樹長得太寬太密？如何使合並的開銷減至最小？
解決方案：簡化分支模型：開發單個產品版本時，在主線上進行開發。分支時，先考慮總體戰略，然后再創建分支
6，分支是組織文件版本和顯示版本歷史的手段，是隔離變更的強有力機制。
7，主線既要使碼線的並發性達到最大，又要使推遲集成可能造成的問題減至最小
8，私有工作區——問題： 如何跟上不斷變化的碼線並取得進展，而不會為環境變化而分心？
-
解決方案：以隔離工作的方法控制變更 (Isolate your work to change control)
-
儲存庫——問題：如何獲得填充新工作區的正確組件的正確版本11，
-
冒煙測試(Smoke Test)：如何知道系統在你變更后仍能工作？
描述的是在將代碼更改嵌入到產品的源樹中之前對這些更改進行驗證的過程；
是確定和修復軟件缺陷的最經濟有效的方法；缺點在於覆蓋面很有限。執行者是開發人員或版本編譯人員
12，每次構造都必須進行冒煙測試，以顯而易見的方式驗證應用未被損壞。
13，單元測試（(Unit Test)）：如何測試模塊經你變更后是否仍能像預期一樣工作？
14，回歸測試（(Regression Test)）：如何確保現有的代碼沒有因你進行其他改進而變得更糟？
15，每日構建 (Daily Build)
就是把一個軟件項目的所有的最新的代碼從配置庫中取出，然后從頭進行編譯、鏈接和運行。通常由工具自動完成（構建自動化）。
daily build 的另一個重要功能就是驗證軟件中各模塊關系是否正確，也可稱為"每日集成"。
第9章
1，版本庫（Repository）：按照一定格式存儲了所有數據，包括文件和目錄
經過授權的客戶端可以連接到版本庫，讀寫庫中的文件
版本庫和普通文件服務器的不同：版本庫會記錄每一次的更改
2，版本控制系統的核心任務：協作編輯和數據共享
3，拷貝-合並模型假定文件是可以通過上下文合並的。通常情況下，文本文件（例如源代碼以及用純文本，HTML，TXT等格式保存的文檔）因為其內部結構直觀可知，容易理解上下文，所以用拷貝-合並方案較好。而二進制文件（例如用Microsoft Word格式說，PDF等格式保存的文檔及圖片，聲音，可執行文件，庫等）內部結構復雜，且不容易理解更改處的上下文，采用鎖定-解鎖方案較好
4，Subversion主要采用拷貝-修改-合並模型，配合鎖定-修改-解鎖模型管理數據的共享
5，工作拷貝（Working Copy）是本地機器的一個普通的目錄，是私有工作區
6，修訂版本（Revision）：每當一次提交完成后，版本庫的文件系統就進入了一個新的狀態，叫做一次修訂（Revision）。在版本庫中，最新的一個修訂版本稱為HEAD
7，CheckOut：從版本庫中取出某個目錄的拷貝到本機上某個目錄的操作
例：svn co svn://192.168.0.1/svnrepos/skizcorp/trunk
-r 1452 會檢出1452版，如果存在的話；-N：不遞歸（僅針對頂層目錄），否則目錄遞歸（默認，常用）
8，Update：把版本庫的修改同步到本地
-
例1：up 直接把工作拷貝更新到最新版（HEAD版）
-
例2：up -r 2007 更新到2007版
-
例3：up doc/design 只更新doc/design下的文件
9，BASE版：某個文件的BASE版本是指存放在管理目錄.svn中的該文件拷貝的版本，Revert會使該文件回到BASE版本
10，Revert，是指放棄對某個文件的修改------revert abc.c 丟棄對abc.c的所有修改
11，當文件發生沖突時，SVN會額外創建3個不受版本控制的文件
12，add：把一個文件加入SVN版本控制系統；delete：從版本控制系統中移除；
move(rename)：移動或者重命名；mkdir：創建目錄；copy：拷貝；commit：提交；
status：檢查工作拷貝的狀態；diff：檢查更改的內容
13，分支(Branch)是開發的一條"支線"。它獨立於其他開發的線路，並且和其他線路並行開發
-
所有的分支都有共同的歷史，有着原先共同的主線(Trunk)
14，創建分支使用copy命令：copy 源目錄 目標目錄
-
例：先把目錄checkout到本地，在本地執行copy命令后提交至版本庫
svn co svn://localhost/
svn copy trunk/ branches/mybranch
svn commit –m "My branch created"
-
svn copy svn://localhost/trunk svn://localhost/branches/mybranch –m "My branch"
15，Switch操作可以使工作拷貝在不同的分支之間或者在位於不同服務器上相同的版本庫的分支間切換。它的作用是改變工作拷貝對應的URL：switch [--relocate] 目標URL
16,分支的合並是指把修改從分支拷貝到主干或者把主干的修改拷貝到分支的過程。
-
傳統方法：diff + patch(只適用於文件內容)
-
例子：取出主干2000版到2007版的修改，然后把它應用到工作拷貝
-
svn diff –r 2000:2007 svn://localhost/trunk > patchfile
patch –p0 < patchfile
-
merge 初始版本樹 最終版本樹 目標(能夠處理目錄樹的修改，而不限於單個文件內容)
例子
-
merge svn://localhost/trunk@2000 svn://localhost/trunk@2007 my_wc
-
merge –r 2000:2007 svn://localhost/trunk my_wc
17,tag：通常tag對應於milestone，是一個完整可用的版本，不能修改，是只讀的
branch：是trunk或tag的分支，可以修改，是可寫的，用於做並行開發
18，常用的SVN命令：
| 命令名稱 |
功能 |
| svn add |
往版本庫中添加新的文件 |
| svn checkout |
將文件checkout到本地目錄 |
| svn cleanup |
遞歸清理工作拷貝 |
| svn commit |
將改動的文件提交到版本庫 |
| svn copy |
拷貝文件 |
| svn delete |
刪除文件 |
| svn diff |
比較差異 |
| svn export |
導出目錄樹 |
| svn import |
導入目錄樹 |
| svn info |
打印作者、時間戳、日志信息大小和日志信息 |
| svn list |
版本庫下的文件和目錄列表 |
| svn lock |
文件加鎖 |
| svn log |
查看日志 |
| svn merge |
將兩個版本之間的差異合並到當前文件 |
| svn mkdir |
創建納入版本控制下的新目錄 |
| svn move |
移動一個文件或目錄 |
| svn resolved |
移除工作副本的目錄或文件的"沖突"狀態 |
| svn revert |
恢復本地修改 |
| svn status |
查看文件或者目錄狀態 |
| svn switch |
代碼庫URL變更 |
| svn unlock |
文件解鎖 |
| svn update |
更新到某個版本 |
第8章
1，兩種版本控制模型
-
Lock-Modify-Unlock Model (加鎖-修改-解鎖)：CVS，SVN，VSS2005
-
Copy-Modify-Merge Model (拷貝-修改-合並)：VSS6.0，PCVS
2，基於"拷貝—修改—合並"的並發控制
-
客戶端check out后，有文件的一份獨立拷貝。
-
開發者在自己的工作目錄中修改文件。
-
若有版本沖突，則使用合並（merge）功能與其它開發者的修改合並，然后提交（check in）。
第6章
1，常用的配置管理工具：Visual SourceSafe（VSS）； CVS； Subversion（SVN）； Borland StarTeam； IBM Rational ClearCase & ClearQuest； Hansky Firefly
ClearCase，Firefly支持異地開發，與開發工具的集成非常好，價格昂貴
VSS僅支持windows,其他支持常見平台，與vs無縫集成，與其他開發工具集成性差
2，軟件配置管理工具的主要功能：
版本控制；變更管理；配置審核（配置審計）
配置狀態統計（查詢和報告）；問題跟蹤（跟蹤缺陷和變更）；訪問控制和安全控制
3，ClearCase主要應用於復雜產品的並行開發、發布和維護，其功能划分為四個范疇：版本控制（Version Control）、工作空間管理（Workspace Management）、構造管理（Build Management）、過程控制（Process Control）。
4，ClearCase把所有版本控制的數據存放在一個永久、安全的存儲區中，這個存儲區被稱為版本對象類（Version Object Bases）
A VIEW selects versions of elements
What is seen is the result of an ordered set of rules called a configuration specification (config spec).
Selected versions appear in a standard directory tree with recognizable file names.
View分為SnapShot View和Dynamic View，Snapshot view是ClearCase在服務器上存儲的文件和目錄的一個本地鏡像，Dynamic View是動態試圖，它並不在本地存儲任何文件，始終和服務器保持一致。
-
軟件配置管理工具選擇：功能；是否符合團隊特點？性能；費用是；售后服務；易用性
| 序號 |
活動名稱 |
角色 |
活動描述 |
參考 |
| 1 |
|
配置管理經理 CCB |
|
《配置管理計划》模板
|
| 2 |
|
配置管理經理 |
|
《VSS使用手冊》 《組織管理配置庫使用指南》 |
| 3 |
|
配置管理經理 |
|
《軟件開發文檔命名約定》 |
| 4 |
|
配置管理經理 集成員 |
|
《配置管理計划模板》
《基線策略指南》 |
| 5 |
|
配置管理經理 |
根據配置管理計划，收集配置活動數據， 編寫配置狀態報告。 |
《配置狀態報告》模板 |
| 6 |
|
配置管理經理 |
|
《配置審計報告》模板 |
| 7 |
|
CCB 任意角色 |
|
《文檔變更請求》 |
