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