什么是軟件配置管理
“一套應(yīng)用技術(shù)上和管理上的指導(dǎo)和監(jiān)督的方法，用來：識別和記錄配置項的功能特征和物理特征；控制這些特征的變更；記錄和報告變更的處理和執(zhí)行的狀態(tài)；以及驗(yàn)證其是否符合特定的需求。”
基本的版本控制：記錄版本，防止混亂
2.2 建立公共存儲區(qū)
公共存儲區(qū)是個星形結(jié)構(gòu)
2.3 防止版本覆蓋
第一種方法 串行的方法（鎖定要修改的代碼）
第二種方法 并行的方法
按任務(wù)單元組織工作
任務(wù)單元（Task）又稱活動(Activity)。
從源代碼的實(shí)際變動的角度看，任務(wù)單元對應(yīng)于一個或多個文件上的一處或多處具體的代碼改動。這些改動組合在一起，通常管它叫一個變更集
注意：每個任務(wù)單元所對應(yīng)的工作量，不要太大。說對應(yīng)的源代碼改動，不要太多。否則，不好查閱修改情況，也不好管理。如果是個很大的任務(wù)單元，那就要考慮把它劃分成若干小一些的任務(wù)單元
3.3 適時的更新工作空間
3.4 保證任務(wù)單元完成的質(zhì)量
保證任務(wù)單元完成的質(zhì)量，進(jìn)而保證整個產(chǎn)品的整體質(zhì)量，是每一個程序開發(fā)者的責(zé)任，絕不僅僅是測試工程師、集成工程師等角色的責(zé)任。
除了自測試外，有的團(tuán)隊還會引入同行評審（Peer Review）,又稱為代碼走查（Code Insepction）.
于此相關(guān)的是有些敏捷開發(fā)團(tuán)隊采用結(jié)對編程（Pair Programming）技術(shù)，目的之一也是提高程序質(zhì)量
作為軟件研發(fā)項目的協(xié)調(diào)者，管理者也需要做些事情，進(jìn)到自己的職責(zé)，比如在產(chǎn)品即將上市，或進(jìn)入維護(hù)期后，管理者要站出來，加強(qiáng)控制，加強(qiáng)評審，保證“讓產(chǎn)品趨于穩(wěn)定，并且盡快上市”這樣的目標(biāo)的實(shí)現(xiàn)
提交后，版本庫里最新版本不能工作怎么辦？？
常用辦法：提交前，更新工作空間到當(dāng)時產(chǎn)品的最新版本。然后，在工作空間里編譯鏈接，并作粗略的測試，證明程序可以運(yùn)行。這之后，在提交。
產(chǎn)品的整體版本
4.1 記錄源代碼的整體版本
整體版本，是項目開發(fā)的某一時刻的全部源代碼的一個“截圖”，行話叫“快照”（Snapshot）。
基線（Baseline）：被明顯地標(biāo)識和記錄下來的源代碼整體版本。
4.2 保存安裝包
可以保存在共享目錄下，該共享目錄可在局域網(wǎng)上共享。
4.3 開發(fā)—測試—發(fā)布
在送交系統(tǒng)測試之前，除了保存源代碼的整體版本，還應(yīng)該保存安裝包。
第五章關(guān)注源代碼整體質(zhì)量
集成的步驟
1、 應(yīng)該確保開發(fā)人員都提交了相關(guān)的源代碼
2、 凍結(jié)或者標(biāo)識將要集成的源代碼
3、 取出要集成的源代碼，最好是存放到一個全新的工作空間
4、 編譯，鏈接和打安裝包。目的是由源代碼生成可以測試、發(fā)布的安裝包。這通常稱為構(gòu)建（build）。
5、 安裝并粗略測試。僅僅能通過構(gòu)建，通常是不夠的。
6、 標(biāo)識和儲存集成成果。集成成果又兩個，一個事源代碼的整體版本，一個是生成的安裝包。它們都要被合理的標(biāo)識和存儲
7、 通知相關(guān)人員，本次集成完成。
間接工作流(Non-immediateWorkflow)：更新到基線而非最新源代碼上的方法。
直接工作流(ImmediateWorkflow)：總是更新到最新源代碼上的方法。
每日構(gòu)建(Daily Build/Nightly Build)：及早和經(jīng)常的集成
持續(xù)集成(Continuous Integration)：持續(xù)集成認(rèn)為，集成應(yīng)該更為繁瑣。
什么時候用到分層集成：內(nèi)部高聚合，外部松耦合的時候需要。
第六章構(gòu)件管理與環(huán)境設(shè)置
構(gòu)建：簡單的說，就是從源代碼生產(chǎn)出安裝包的過程。
從源代碼到安裝包這一生成轉(zhuǎn)換過程，要有足夠的管理，確保其可重復(fù)性。
1、 原材料是固定和明確的。
2、 工具是固定和明確的
3、 參數(shù)設(shè)置也必須是固定和明確的。這在具體執(zhí)行編譯、鏈接和打包的命令參數(shù)上體現(xiàn)出來
4、 生產(chǎn)過程是固定和明確的。
想要做到這一點(diǎn)，一個好的辦法是自動化，盡可能的自動化。
全量構(gòu)建與增量構(gòu)建
全量構(gòu)建：從頭來過，從每一個源文件的編譯開始
增量構(gòu)建：盡可能地利用上次構(gòu)建的成果。增量構(gòu)建的輸入，不僅包括原材料，還包括上次構(gòu)件中，產(chǎn)生的中間產(chǎn)品，比如編譯產(chǎn)生的很多中間文件。
記錄構(gòu)建相關(guān)信息：
1、 構(gòu)建是怎么定的，怎么配的。
2、 構(gòu)建的執(zhí)行情況。
環(huán)境和設(shè)置：不止是在構(gòu)建的時候
軟件開發(fā)相關(guān)的環(huán)境：構(gòu)建環(huán)境、開發(fā)環(huán)境、運(yùn)行環(huán)境。
管理是發(fā)現(xiàn)、傳播和共享的過程
第七章分支：減少等待，分頭工作
文件級分支
產(chǎn)品級分支
典型應(yīng)用一：實(shí)現(xiàn)多層集成
典型應(yīng)用二：實(shí)現(xiàn)交迭
分支為什么這樣有用：
1、 適當(dāng)隔離
2、 適當(dāng)共享
工作空間：本質(zhì)是以產(chǎn)品的一個整體版本為起點(diǎn)，再加上一個未完成的任務(wù)單元。
工作空間支持隔離，支持共享
分支和工作空間都支持隔離和共享，為什么同時需要這兩個：
兩者各有優(yōu)勢和劣勢，它們之間是相互配合、相互補(bǔ)充的關(guān)系，而不是相互替代的關(guān)系。
1、 分支無法代替工作空間。工作空間可以容納未完成的任務(wù)單元，尚未檢入和提交的修改，正在時時刻刻不斷變化的修改，因此直接支持開發(fā)人員的日常工作。無論是否使用分支，一定要使用工作空間。
2、 只使用工作空間，不使用分支，常常是不夠的。分支又3個優(yōu)勢：
A、可以同時容納多個已提交的任務(wù)單元，并以此和其他分支相區(qū)別----工作空間只能容納一個未完成的任務(wù)單元
B、分支存儲在服務(wù)器上，比存儲在本地的工作空間要安全
C、分支是所有人都能看見的，并且如果有必要，所有人都能在其上工作，而工作空間是單個開發(fā)人員自己的地盤，只有他可以在里面工作
分支有個弱點(diǎn)，就是不能改變其起始點(diǎn)。
第八章管理文檔
文檔的標(biāo)識和存儲
它們與源代碼的不同主要體現(xiàn)在兩方面：
1、 “文責(zé)自負(fù)”，因此，對文檔的修改的協(xié)調(diào)，通常是用鎖機(jī)制，或者干脆就不提供自動機(jī)制。
2、 “獨(dú)立成篇
自帶的說明信息
文檔常有明確的所有者，由他修改，其他人只是閱讀。文檔通常獨(dú)立成篇，文檔間的耦合性不強(qiáng)。因此文檔的傳遞和復(fù)制，通常管制比較松。這就要求，文檔本身的一些信息，比如版本信息等，要由它自身攜帶。
文檔中起始的一到二頁，常常用來更全面地記錄和展現(xiàn)相關(guān)信息：
1、 關(guān)于文檔的名稱，在文件名中，可能只是以縮寫體現(xiàn)的。在文檔中就應(yīng)該給出文檔名稱的全名。
2、 應(yīng)該以某種方式，指出文檔的“出處”。
文檔通常會有一定的密級，不同的文檔，密級可能不同。應(yīng)該在文檔起始頁明確標(biāo)出文檔的密級，讓使用者留意自己的行為。這是公司司法務(wù)部門特別關(guān)注的，他們同樣關(guān)注版權(quán)信息。這通常也明確標(biāo)識在文檔的起始處。
對于當(dāng)前版本的信息，主要有三項：1、版本號 2、版本產(chǎn)生時間 3、版本目的或狀態(tài) 對于文檔也類似
文檔的狀態(tài)，通常有如下三種：1、草稿(Draft) 2、評審中(InReview) 3、已發(fā)布(Released)
文檔的作者和參與者的信息，也應(yīng)該被記錄。比較全面的的記錄內(nèi)容包括：
l
誰是這份文檔的主人，對文檔的內(nèi)容及文檔書寫的協(xié)調(diào)工作責(zé)任？
l
哪些人是這份文檔的主要作者，書寫了這份文檔的絕大部分內(nèi)容？對于中小型文檔，通常主要作者只有一個人，且他就是文檔的主人。
l
哪些人為這份文檔做出了貢獻(xiàn)，包括正式的評審和非正式的建議等？
l
如果這份文檔是已經(jīng)被批準(zhǔn)，正式發(fā)布的文檔，那么，是那些人批準(zhǔn)的，以誰的名義發(fā)布的?
關(guān)于版本歷史信息。每次修改并保存版本，通常要記錄如下信息：
l
修改后的版本號
l
修改完成的時間
l
本次修改的修改者
l
這個版本的最終狀態(tài)
l
對修改的簡單描述
趨勢：WIKI
如果想知道關(guān)注的特定內(nèi)容在哪個文檔里，就得依次打開各個文檔，看其簡要介紹。為了去除這些不便之處WIKI產(chǎn)生
WIKI首先是一種語言，一種像HTML一樣的既有內(nèi)容，又有格式的語言。
登陸WIKI系統(tǒng)，在特定頁面的可編輯區(qū)域里，用WIKI語言書寫，修改和保存。而在展現(xiàn)給別人的時候，WIKI系統(tǒng)會自動把它翻譯成了HTML語言，在瀏覽器中顯示。
WIKI定位與“面向社群的協(xié)作式協(xié)作”。它很好的做到了這一點(diǎn)。
趨勢：數(shù)據(jù)文件和數(shù)據(jù)庫
更好的方法是用一套需求管理工具來管理需求信息。每個需求是一個條目，條目可以有各種屬性；條目有它的修改歷史；條目之間的關(guān)系被記錄，一旦一個條目被修改，相關(guān)的條目會被提醒要不要修改，等等。需求管理工具把這些數(shù)據(jù)，保存在特定各式的數(shù)據(jù)庫文件里，或者數(shù)據(jù)庫里。使用需求管理工具來記錄和管理需求，比用一般文檔文件來記錄和管理需求，要方便地多
還有些工具，為軟件開發(fā)活動提供支持。這里，討論關(guān)于這些工具所保存和使用的數(shù)據(jù)的管理工作。這些數(shù)據(jù)，同樣是軟件項目的資產(chǎn)，同樣應(yīng)該進(jìn)行軟件配置管理。這主要通過兩種途徑實(shí)現(xiàn)：
由相關(guān)工具本身提供一定的軟件配置管理功能。
對數(shù)據(jù)文件或數(shù)據(jù)庫，進(jìn)行外在的、整體的管理。
途徑一和途徑二相輔相成。
第九章
跟蹤缺陷，直到消滅
Bug跟蹤系統(tǒng)，學(xué)名叫缺陷跟蹤系統(tǒng)（Defect Tracking System.）
發(fā)現(xiàn)了這個缺陷，并且報上來。（Reported已報告）
大致看看這個缺陷，并分配給合適的程序員去處理。(Assigned已分配)
解決這個缺陷，這道工序由程序員來完成。（Resolved已解決）
確定這個缺陷真的被修復(fù)了(Closed已關(guān)閉)
準(zhǔn)確記錄，便于修復(fù)
每條缺陷記錄，有一行標(biāo)題（Title）,或者叫總結(jié)(Summary),簡述缺陷的內(nèi)容。
還有一些字段能起到類似作用，比如關(guān)鍵字（Key Words）。
對于真正修改源代碼以修復(fù)缺陷的程序員而言，它們需要對缺陷的詳細(xì)描述，這通常通過讓缺陷報告者填寫細(xì)節(jié)描述(Description)區(qū)域來實(shí)現(xiàn)
對缺陷的詳細(xì)描述，一定要做到可以復(fù)現(xiàn)這個缺陷。要詳細(xì)記錄當(dāng)時的操作環(huán)境，當(dāng)時的操作步驟，以及當(dāng)時的缺陷現(xiàn)象。 對缺陷的詳細(xì)描述，是處理缺陷和檢驗(yàn)處理結(jié)果的依據(jù)，十分重要！
在有些缺陷跟蹤跟蹤系統(tǒng)里，除了可以用文字詳細(xì)描述缺陷外，還可以上傳相關(guān)附件，比如，當(dāng)時缺陷情況的截圖或使得程序保存的輸入數(shù)據(jù)文件等。
救護(hù)是依據(jù)傷員布條的顏色，修復(fù)缺陷也有類似的屬性。它們是兩個：嚴(yán)重程度和優(yōu)先級
我們需要遵循一個原則，那就是，避免帶著許多缺陷前進(jìn)，缺陷應(yīng)該盡快被消滅。
關(guān)聯(lián)缺陷記錄與任務(wù)單元
缺陷記錄與任務(wù)單元之間的關(guān)系，并不一定總是一對一的關(guān)系。有的缺陷的修復(fù)，需要對程序有比較大的調(diào)整，需要多個人一起配合，于是，需要有多個任務(wù)單元。而另一些時候，幾個相關(guān)的缺陷，可能是通過一個任務(wù)單元就都修復(fù)了
分析統(tǒng)計缺陷相關(guān)數(shù)據(jù)
在缺陷管理方面，我們有典型的三類統(tǒng)計。這三類統(tǒng)計，各有益處：
用來回答缺陷是怎么分布、數(shù)量是多少。
用來回答隨著時間的遷移，缺陷的總體趨勢是什么樣的。
關(guān)于缺陷年齡的統(tǒng)計。
另一種展現(xiàn)方式，是報表：報表的好處是，文字上的東西可以多些；具體的數(shù)字，可以看的更清楚些；交給領(lǐng)導(dǎo)，也更像樣子。
第十章管理變更
比缺陷更廣闊的話題，是變更請求，比變更請求更廣闊的話題，是變更。
變更在不同的文檔中，在不同的上下文中，有不同的含義，而我們更關(guān)心的是功能需求上的變更請求，架構(gòu)設(shè)計上的變更請求。
管理細(xì)小的變更
功能增強(qiáng)（Enhancement）：指一些小小的請求，請求吧程序已有的功能，稍稍增強(qiáng)一點(diǎn)，或者稍稍改變一下。
對這類請求的管理，就有點(diǎn)像缺陷的管理：缺陷的特點(diǎn)1、數(shù)量多，容易丟；2、通常每個涉及的改動工作量都不大，經(jīng)常是一個任務(wù)單元就能完成；3、通常每個缺陷都能明確對應(yīng)到源代碼的改動；4、通常缺陷之間相互獨(dú)立，不要通盤考慮。 正是因?yàn)檫@樣的特點(diǎn)，所以把缺陷按條目記錄，進(jìn)而分別跟蹤、處理，直至解決。
但是功能增強(qiáng)的處理流程，與缺陷的處理流程，也有所不同。這主要體現(xiàn)在兩點(diǎn)上：
需要對功能增強(qiáng)有仔細(xì)的評估，進(jìn)而確定是否要實(shí)現(xiàn)。
功能增強(qiáng)所導(dǎo)致的修改，常常不僅是源代碼的修改。
在瀑布模型中管理變更
瀑布模型希望能夠借助在傳統(tǒng)工程中的成功經(jīng)驗(yàn)，來實(shí)現(xiàn)軟件開發(fā)項目的成功。
瀑布模型希望也能用這樣的方法進(jìn)行軟件開發(fā)。
在瀑布模型中，變更的管理很重要。其主要的關(guān)注點(diǎn)是：一但定下來的事，就要執(zhí)行，不能亂改。要減少變更，變更不能隨意發(fā)生。所以，變更管理的核心是，嚴(yán)格控制變更。
一個常見的做法，設(shè)立變更控制委員會（Change Control Board,CCB）
在迭代模型中管理變更
它的思想核心是，盡早反饋。
迭代式開發(fā)把一個大項目在時間軸分解成很多個小項目，每個小項目被稱作一個迭代（Iteration）。幾乎每次迭代都會包含需求分析，系統(tǒng)設(shè)計，代碼實(shí)現(xiàn)，以及集成和測試。
在每次迭代的過程中，通常不會接受新的變更，特別是比較大的變更。每次迭代的時間不長，一般只是三四個星期，應(yīng)該集中精力在要做的事情上，而不是對要做什么猶豫不決。
影響變更控制的因素
作為嚴(yán)格的變更控制，需要在變更提出時，填寫足夠詳盡的相關(guān)信息。然后是足夠的變更評估，評估變更影響的方方面面。之后，做出變更決定。這也要經(jīng)過充分討論，并最終取得一致。接著，是變更的實(shí)施，對源代碼和文檔的改動。變更實(shí)施后，要經(jīng)過足夠的測試和驗(yàn)證，保證變更真的發(fā)生了，真的正確地發(fā)生了。
不是所有的變更，都要經(jīng)歷這么嚴(yán)格的控制,那么，哪些因素會影響對變更的控制程度和控制流程呢？
l
變更的類型
l
變更的大小
l
變更的影響面
l
變更的風(fēng)險
l
變更發(fā)生的時間
l
研發(fā)規(guī)模
記錄產(chǎn)品版本間的差異
發(fā)布給用戶的文檔，除了關(guān)于整個產(chǎn)品的描述文檔，比如使用手冊外，還要有關(guān)于版本間差異的說明。這通常在發(fā)布說明（Release Notes）文檔中實(shí)現(xiàn)。
現(xiàn)在，我們重點(diǎn)關(guān)注版本間差異的說明。我們?nèi)绾萎a(chǎn)生這個說明？信息從哪兒來？
有四個途徑：
查看版本控制系統(tǒng)。
查看變更請求數(shù)據(jù)庫
查看項目計劃或迭代計劃
查看需求數(shù)據(jù)庫或需求文檔
控制產(chǎn)品版本間的差異
在版本控制系統(tǒng)里，我們可以加一些控制，以保證程序員做且只做該做的事：
第一種方法是，讓任務(wù)單元不是由程序員創(chuàng)建，而是由管理人員創(chuàng)建，然后指定給相應(yīng)的程序員完成。
第二種方法是事后控制。在程序員完成了任務(wù)單元后，如果想提交，需要得到某種批準(zhǔn)。只有符合本次版本需要的任務(wù)單元，才可以提交。
第十一章產(chǎn)品整個生命周期內(nèi)的配置管理
制定計劃
計劃文檔的內(nèi)容及詳略在不同的項目間有極大的差異。計劃文檔內(nèi)容及繁簡，主要受以下幾方面因素的影響：
組織級軟件配置管理系統(tǒng)建設(shè)的情況，包括工具
特定項目“與眾不同”的程度。越是特殊的項目，越需要更多的計劃，并體現(xiàn)為計劃文檔的內(nèi)容。
特定項目的軟件配置管理的復(fù)雜性。
軟件配置管理計劃中的內(nèi)容，可能會隨著時間的推移、項目的進(jìn)展而改變。應(yīng)該積極面對這樣的變化，適當(dāng)調(diào)整計劃，并反映在計劃文檔上。文檔需要持續(xù)維護(hù)。
做好準(zhǔn)備
軟件配置管理系統(tǒng)，可大致分為工具、過程和人三個方面。要做好軟件配置管理系統(tǒng)的運(yùn)行準(zhǔn)備，就要做好這三個方面的準(zhǔn)備
監(jiān)控、調(diào)整與改進(jìn)
軟件配置管理系統(tǒng)的運(yùn)行，既需要參與者的深刻理解和自覺執(zhí)行，也需要某種形式的監(jiān)控。
第一類調(diào)整：項目的軟件配置管理策略、方法，需要隨著項目的緊張進(jìn)行調(diào)整。
第二類調(diào)整：在制定計劃時，不能準(zhǔn)備地估計到項目對軟件配置管理的需求；不能準(zhǔn)確地估計到在這個項目中，各項軟件配置管理工作應(yīng)該怎么做，應(yīng)該做到什么程度。
隨著對軟件配置管理的認(rèn)識不斷提高，會對流程進(jìn)行調(diào)整；隨著新的軟件配置管理工具的選型、購買、安裝設(shè)置的完成，會對項目所用工具進(jìn)行調(diào)整。這類以提
升為主要特征的調(diào)整，通常被稱為改進(jìn)。
收尾
在產(chǎn)品發(fā)布、項目收尾階段，軟件配置管理同樣需要進(jìn)行收尾工作。這主要包括兩個方面，軟件資產(chǎn)的整理和歸檔工作、軟件配置管理本身的總結(jié)和共享工作。
第十二章玄妙的學(xué)院派
配置管理由配置識別、配置控制、配置狀態(tài)報告、配置審計四部分組成。
配置識別（Configuration Identification）
包括選擇產(chǎn)品的配置項、為它們指定唯一的標(biāo)識，并在技術(shù)文檔中記錄其功能和物理的特征。
配置控制 (Configuration Control)
包含評估、協(xié)調(diào)、批準(zhǔn)/拒絕、實(shí)施對配置項的變更。這應(yīng)該發(fā)生在正式的配置識別之后
對于變更，還有協(xié)調(diào)的工作要做，這主要體現(xiàn)在三個方面：
在不同的變更請求之間的關(guān)聯(lián)性。
一個變更請求，可能會影響到不同的產(chǎn)品，因?yàn)樗M(jìn)行的改動，是在一個公共組件上，這個組件被好幾個產(chǎn)品使用。
體現(xiàn)在完成的先后順序上，有的請求比較緊急，有的請求比較重大，要優(yōu)先安排人力資源去完成，有些則可以拖一拖。
配置狀態(tài)報告 (Configuration Status Report)
記錄和報告用來有效管理配置所需的必要信息。這些信息包括一個已批準(zhǔn)的配置識別清單，變更請求當(dāng)前的處理狀態(tài)，以及已批準(zhǔn)的變更的實(shí)現(xiàn)情況。
配置審計 (Configuration Audit)
執(zhí)行審計以驗(yàn)證配置項符合特定的標(biāo)準(zhǔn)或需求
配置審計定義中所說的審計，是指對象本身是否符合需求和相關(guān)的標(biāo)準(zhǔn)，而不是制作對象的過程。
那么軟件配置項的審計，是指什么呢？
首先，是要確保需求文檔反映了客戶的需求，設(shè)計文檔反映了需求文檔的要求，源代碼實(shí)現(xiàn)了設(shè)計文檔的目標(biāo)。這樣一層層遞進(jìn)，以確保跑起來的程序，就是客戶想要的。
其次，在源代碼寫完之后，要進(jìn)行單元測試；集成時，要做粗略測試；進(jìn)而，由系統(tǒng)測試團(tuán)隊進(jìn)行系統(tǒng)測試；最后，由用戶或用戶代表進(jìn)行接受測試。
審計又被分為功能審計和物理審計
在相關(guān)標(biāo)準(zhǔn)里
在能力成熟度集成模型（Capability Maturity Model
Integration,CMMI）中，對包括軟件配置管理在內(nèi)的配置管理工作，從如下角度進(jìn)行了劃分。
l
建立基線
首先，識別配置項；接著，建立配置管理系統(tǒng)，用來存放配置項；最后，通過評審或測試后，由配置項組成基線，作為未來開發(fā)的基礎(chǔ)。
l
建立并控制變更
l
建立完整性
首先，要對配置管理活動做足夠的記錄；其次，要進(jìn)行配置審計。
以上3個方面，是針對配置管理的要求。還有兩方面，使用于各方面的管理，配置管理也需要：
l
制度化已管理過程
在一個軟件研發(fā)項目中做配置管理，首先要建立配置管理計劃，然后確保有足夠的資源，包括工具、環(huán)境、也包括人員。在配置管理系統(tǒng)運(yùn)轉(zhuǎn)過程中，要適當(dāng)監(jiān)控。
l
制度化已定義過程
要形成可以指導(dǎo)現(xiàn)在和未來多個軟件研發(fā)項目的配置管理過程規(guī)范。這樣的規(guī)范不是一成不變的。要收集相關(guān)的信息、數(shù)據(jù)和反饋，并基于此，進(jìn)行軟件配置管理的持續(xù)的改進(jìn)。
在軟件能力成熟度模型（Capability
Maturity Model for Software,SW-CMM）
l
執(zhí)行約定
l
執(zhí)行能力
l
執(zhí)行的活動
l
度量和分析
l
驗(yàn)證實(shí)施
-- 
學(xué)海無涯