jasmine214--love

    WHAT-----早在七十年代初期加利福利亞大學的Leon Presser教授就撰寫了一篇論文，提出控制變更和配置的概念，之后在1975年，他成立了一家名為Soft Tool的公司，開發了自己的配置管理工 具：CCC，這也是最早的配置管理工具之一。之后，隨著軟件開發規模的逐漸增大，越來越多的公司和團隊意識到了 軟件配置管理的重要性，而相應的軟件配置管理工具也如雨后春筍一般，紛紛涌現，比較有代表性的有：Marc Rocking的SCCS(Source Code ControlSystem)和Walter Itchy的RCS(RevisionControl System)，這兩種工具對日后的配置管理工具的發展做出了重大的貢獻，目前絕大多數廣泛使用的配置管理工具基本上都是基于這兩者的設計思想和體系架構。什 么是軟件配置管理呢？軟件配置管理有多種定義，在1986年出版的Wayne Babyis《SoftwareConfigurationManagement:Coordinating for Team Productivity》一書中把軟件配置管理描述為"對軟件開發組所建立的軟件的修改 進行標識、組織和控制的藝術，其目標是減少錯誤，提高生產力"。這個定義比較簡單，而在1993年出版的Steve McConnell的《Code Complete》一書中，從另一個角度對軟件配置管理進行了定義："配置管理能夠系統地處理變更，從 而使得軟件系統可以隨時保持其完整性。配置管理又可稱為'變更控制'，可以用來評估提出的變更請求， 跟蹤變更，并保存系統在不同時間的狀態。" 軟件配置管理是一套規范、高效的軟件開發基礎結構。作為管理軟件開發過程 有效的方法，SCM早已被發達國家軟件產業的發展和實踐所證明。SCM可以系統地管理軟件系統中的多重 版本；全面記載系統開發的歷史過程，包括為什么修改，誰作了修改，修改了什么；管理和追蹤開發過程中危害軟件質量以及影響開發周期的缺陷和變化。SCM對開發過程進行有效地管理和控 制，完整、明確地記載開發過程中的歷史變更，形成規范化的文檔，不僅使日后的維護和升級得到保證，而且更重要的是，這還會保護寶貴的代碼資源，積累軟件財 富，提高軟件重用率，加快投資回報。SCM是通往ISO9000和SEI CMM標準的一塊基石。在軟件開發團隊 中，正確地采用、實施軟件配置管理系統，必將提高生產力，增強對整個項目的控制，改善軟件產品的質量，從容面對快速面市和產品質量的雙重壓力。軟件配置管 理系統的實施，一般來講要考慮兩個方面的因素：流程和工具。流程和工具是相輔相成的，流程起決定性作用，它確定了管理的規則和方法，工具用來將變更存儲在 一個中央存儲庫中，可以重現任一時期的歷史版本，一個好的工具可以提高效率，是貫徹實施流程的必要手段。因此，在一個開發團隊中，實施配置管理流程比采用 配置管理工具更重要，我們需要充分考慮，制定出適合自己企業的配置管理流程，該流程必須與公司的開發規范、質量系統等完全結合。

      在軟件開發中，變更是不可避免的。從某種角度上講，軟件開發過程就是一個變更的過程。有些變更是有益的，是具有創造性的，但是，也有些變更是有害的，導致 混亂的。正像James Bach 總結的那樣：我們為變更所困擾，因為代碼中的一個極小的混亂可能帶來產品的大的故障，但是，他也能夠修復大的故障或啟用奇妙的新能力。我們為變更所困擾， 因為某個喜歡惡作劇的單個開發者可能破壞掉項目，但是，一些奇妙的思想也源自那些喜歡惡作劇的人員。
因此，如何管理這些變更是一個軟件開發能否成 功的關鍵。簡言之，
軟件配置管理就是管理變更的過程，它貫穿著幾乎軟件的整個生命周
期。成功的配置管理系統可以提高產品的質量、項目開發 效率，而且最大限度的減少對個別“英雄”式人員的依賴。
     軟件開發過程的輸出信息可以分為三個主要的類型：(1)計算機程序（源代碼、中間代碼和可執行程序），（2）描述計算機程序的文檔（針對技術開發者和用 戶），（3）數據（包含在程序內部或在程序的外部）。這些項包含了所有的在軟件過程中產生的信息，總稱為軟件配置。該集合中每一個元素稱為該軟件產品軟件 配置中的一個配置項（CI,Configuration Item）。盡管配置管理（Configuration Management ）這個概念被提出有幾十年了，但是，業內還沒有一個全面而權威的定義。Configuration 的
意思是“使成形”，它來源于拉丁語的 com-（表示“與”或者“一起”）和figurate (形成)。它還有一個意思是“組成部件或元素的相對排列”。因此，配置管理（Configuration Management ）指的是管理組成部件或者元素的相對排列。配置管理的概念來自于硬件領域，美國國防部最早使用了配置管理的概念。
我們知道一架飛機的構成非常復 雜，比如機頭、機身、機翼和機尾
等。不同型號飛機的各個部分是不能隨便組裝的。因此，我們只有把相匹配的部件組裝在一起，才能構成了一個功能完備 的飛機整體。隨著技術的提高，各個部件可能還要進行功能改善，我們還要使得不同版本的部件能夠正確無誤組合在一起。
     準確地說：配置管理是對產品進行標識、存儲和控制，以維護其完整性、可追溯性以及正確性的學科。

    WHY----在團隊開發的模式中，軟件開發管理就顯得更加重要，其管 理的好壞將直接影響到軟件產品的質量。如果缺乏對軟件開發的統一管理，勢必造成以下問題的出現：
● 由于開發經費及開發時間的限制，不可能一次開發就解決
所有問題，許多問題有待維護階段解決，因此帶來的是軟件產品的不斷
升級，而維護和升 級所必需的文檔往往非常混亂；
● 開發商開發過程缺乏規范化的管理，即使有源程序文檔也由
于說明不詳細而不能對產品進行進一步的功能擴 充，用戶不得不再投入
大量的經費去開發新產品，浪費大量的人力、物力和時間；
● 在軟件的團隊式開發中，人員流動在所難免，如管理不善，
有 些人員的流動將對開發產生致命的影響。特別是軟件開發管理人員或
核心成員的流失，有可能造成無法確定軟件產品中各模塊所處的狀態及
階段， 使軟件產品的版本出現混亂，甚至可能泄漏公司的核心機密；
● 管理不善致使沒經測試的軟件加入到產品中，不但影響產品
的質量，有時還會導 致致命的錯誤，造成不可挽回的損失；
PDF 文件使用 "pdfFactory Pro" 試用版本創建
● 用戶與開發商沒有有效的溝通手段，用戶投入了開發費用
后，得到的是有關可執行程序以及一堆雜亂無章的文檔，即使是較好的
文檔，對不熟悉開 發過程的專業人員來說也無從下手，更談不上日后的
維護和升級，用戶的利益無法保證；
● 軟件生產達不到規模化，無法生產出軟件企業內部的軟件
標準構件倉庫，使應用軟件產品總處于一種低水平、重復開發的狀態，不但時間得不到保證，而且 成本也無法降低，使產品沒有市場競爭力。這些問題在實際開發中表現為，項目組成員溝通困難，軟件重用率低下，開發人員各自為政，代碼冗余度高，文檔不健全 等；造成的結果是：數據丟失，開發周期漫長，產品可靠性差，質量低劣，軟件維護困難，用戶抱怨使用不便，項目風險增加等。
    HOW----配置標識就是識別產品的結構、產品的構件及其類型，為其分配唯一 的標識符，也就是說，每一個配置項要有一個唯一標識。一般說來，標識包括兩個方面：一是文件名，二是版本，可用如下一個二元組來標識：<文件名，版 本>。每個項目首先要確定一套命名規則，例如，采用“系統.子系統.模塊.文件”的方式，</videoConference /audio/compressing /main.c , 2.1>就是一個唯一.標識。
  版本控制
版本控制就是對在軟件開發過程中所創建的配置對象的不同版本
進行管理， 保證任何時候都能取到正確的版本以及版本的組合。
軟件配置管理基線管理 變更請求管理 發布管理 構建管理
配置標識 版本控制 變更控制 配置狀態統配置審核當前，這方面典型的工具有如VSS 和CVS。
 變更控制
在軟件開發過程，要產生許多變更，比如，配置項、配置、基線、
構建的版本、發布版本等。對于所有的 變更，都要有一個控制機制，以保證所有變更都是可控的、可跟蹤的、可重現的。對變更進行控制的機構稱為變更控制委員會（Change Control Board，簡稱CCB）。變更控制委員會要定期召開會議，對近期所產生的變更請求進行分析、整理，并做出決定。而且要遵循一定的變更機制。
下面 是一個典型的變更機制：
接受 拒絕提交變更請求管理變更請求管理就是對變更請求（Change Request，簡稱CR）進行分類、追蹤和管理的過程來實現的。
變更的起源有兩種：功能變更和缺陷修補（Bug-Fix）。功能變更
是 為了增加或者刪除某些功能。缺陷修補則是對已存在的缺陷進行修
修改測試或驗證對變更請求的有效管理可以提高產品管理的透明度，經理可以清楚的知道 當前產品的進展情況，比如有多少個新產生的CR，已經解決了多少CR 等等，有利于經理做出正確的決策。
基線管理
基線是指經過正式評審和批準，可作為下一步工作的基準的一個配
置。軟 件開發過程中，無論是需求分析、設計、測試都需要在完成時建立基線，以作為下一步工作的基礎。通過基線管理可以使用戶能夠通過對 適當版本的選擇來組成特定屬性（配置）的軟件系統，這種靈活的“組裝”策略使得配置管理系統像搭積木似的使用已有的積（版本）組裝成各種各樣、不同功能的 模型。基線的變更需要一個嚴格的流程，需要提出申請，經過審批，然后才能進行。
構建管理
在做構建時，我們需要首先取出正確的配置，然后再做構建。我們
可以利用基線，可以取出某 個基線的所有配置項，也可以利用配置管理系統的構建功能直接在工作空間內做構建。構建管理需要配置管理工具的支持。
發布管理
軟件產品的每個版本都是一組配置項（源代碼、文 檔、數據）的集
合。舉個例子來說，我們要發布軟件的32.6 版本，那么我們就要把源
代碼、文檔、數據中所有應該包含到這個版本中的正確 配置項檢出。
所以如何管理每個版本中包含哪些配置項是非常重要的。
狀態報告狀態報告要回答所謂4W 的問題：
What：發生了什 么事？
Who：誰做的此事？
When：此事是什么時候發生的？
Why：為什么做此事？
狀態報告要能夠報告所有配置項以及 變更請求的狀態，通過量化的
數據和報表反映項目開發進度的狀態。
配置審核
配置審核要審查整個配置管理過程是否符合規范，配置項是否與需
求一致，記錄正確，配置的組成是否具 有一致性等等。比如，需求分析文檔提交后，需要由一個由相關人組成的小組進行正式評審，只有通過了評審才能基線化。對于源代碼也一樣，一般說來，每行代碼 都要進行評審（Review），只有通過評審才能交由測試人員進行測試。
實施配置管理的好處我們知道軟件有三個要素：時間、預算和質量。一個成功 的軟件就是要在限定的時間內，不超過預算，交付符合質量要求的產品。真正實施配置管理后，我們會對產品的開發過程進行有效的控制，可以加快開發進度，降低 開發成本，保證產品的質量。
     產品經理可以得到什么好處呢？
準確掌握項目的開發進度。配置管理系統可以提供詳盡的狀態報告，例如 當前系統有多少個Bug，所有Bug 的狀態如何？已經解決了多少Bug？了解項目組成員的工作負荷、工作效率以及工作質量。例如，我們可以知道當前分配給每個成員的工作量，每個成員已完成的 工作量，每個成員未通過正式評審的工作比例等等。減少人員流動所帶來的影響。每個成員的所有變更，包括文檔、代碼的增刪都是可追蹤的，而且對于變更的原 因、描述也都有記錄。樣，一旦成員離開，其它成員就可以在最短的時間里接手。有效提高過程管理，配置管理產生的許多數據可作為管理者度量項目的依據。