基線的基本概念

基線(baseline)——經過正式審查和認可作為以後進一步演進的基礎，並且只有通過正式的更改控制規程才能進行更改的規格說明或產品。[IEEE—STD—610]

（注：很多資料寫為進一步開發的基礎，但我覺著演進這個詞比較貼切。維基這樣定義基線：In configuration management, a "baseline" is an agreed-to description of the attributes of a product, at a point in time, which serves as a basis for defining change. A "change" is a movement from this baseline state to a next state. The identification of significant changes from the baseline state is the central purpose of baseline identification.  意為：在配置管理中，“基線”是一個被認可的產品屬性的描述，這個時間點作為基礎服務於定義的變化。“變化”是基線狀態移動到下一狀態的運動過程。基線識別的中心目的是通過基線狀態的顯著變化進行的。）

軟體基線庫(software baseline library)——用以存放配置項和相應的記錄的倉庫的內容。

基線配置管理(baseline configuration management)——建立經正式審查和認可並作為進一步開發工作的基礎的基線。有些軟體工作產品，如軟體設計和程式碼，應該有在預定點上建立的基線，並且對這些基線應該施加嚴格的更改控制過程。當與顧客打交道時，這些基線提供控制和穩定性。

基線管理(baseIine management)——在配置管理中，運用技術和行政指令指定一些文件和對這些文件的更改，這些文件在配置項的生存期內的某些特定時刻，正式標識出和建立起基線。[IEEE—STD—610]

基線的分類

基線分類：按照線性過程開發的軟體工作產品分為Allocate、Requirement、Design、Coding、Integration、Test等階段，可以相應的把基線分為需求基線、設計基線、產品基線等。（注：曾經見過有公司把基線分為十幾個類的，感覺實無此必要，徒增繁重的工作，也沒有見到管理上有什麼優勢。以老張的實際經驗，分為需求基線和產品/專案基線兩類就夠用了，無論開發模式是線性或者敏捷、迭代、螺旋，這兩類都遊刃有餘了。）

PS：為什麼這麼費心的扣這些概念的字眼，因為我一直認為概念是進行持久工作和團隊合作的基礎。只有確定的、鐵板釘釘的概念表述，才能不至於因為理解差異、或者遺忘而發生概念漂移。沒有這些概念表述，天知道你嘴裡的這個詞，在他那裡會理解成什麼東東呢？所以——做事之前，先求共識；開發之前，必寫文件。

“概念漂移”來自資料探勘，這樣說的：概念漂移(concept drift)通常是指隱含內容(hidden context)的改變會或多或少從根本上導致目標概念(target concepts)的改變。真是形象而且精煉啊。