如何構造軟件企業的配置管理方案
朗訊科技(中國) 貝爾實驗室 劉江華
1 引言
1.1 什麼是配置管理
配置管理(Configuration Management)是通過技術或行政手段對軟件產品及
其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟件
產品的演化過程，確保軟件開發者在軟件生命周期中各個階段都能得到精確的產品
配置。
配置管理過程是對處於不斷演化、完善過程中的軟件產品的管理過程。其最
終目標是實現軟件產品的完整性、一致性、可控性，使產品極大程度地與用戶需求
相吻合。它通過控制、記錄、追蹤對軟件的修改和每個修改生成的軟件組成部件來
實現對軟件產品的管理功能。
1.2 配置管理在軟件開發過程和項目管理過程中的作用
隨著軟件系統的日益復雜化和用戶需求、軟件更新的頻繁化，配置管理逐漸
成為軟件生命周期中的重要控制過程，在軟件開發過程中扮演著越來越來重要的角
色。一個好的配置管理過程能覆蓋軟件開發和維護的各個方面，同時對軟件開過程
的宏觀管理，即項目管理，也有重要的支持作用。良好的配置管理能使軟件開發過
程有更好的可預測性，使軟件系統具有可重復性，使用戶和主管部門用軟件質量和
開發小組有更強的信心。
軟件配置管理的最終目標是管理軟件產品。由於軟件產品是在用戶不斷變化
的需求驅動下不斷變化，為了保證對產品有效地進行控制和追蹤，配置管理過程不
能僅僅對靜態的、成形的產品進行管理，而必須對動態的、成長的產品進行管理。
由此可見，配置管理同軟件開發過程緊密相關。配置管理必須緊扣軟件開發過程的
各個環節：管理用戶所提出的需求，監控其實施，確保用戶需求最終落實到產品的
各個版本中去，並在產品發行和用戶支持等方面提供幫助，響應用戶新的需求，推
動新的開發周期。通過配置管理過程的控制，用戶對軟件產品的需求如同普通產品
的訂單一樣，遵循一個嚴格的流程，經過一條受控的生產流水線，最後形成產品，
發售給相應用戶。從另一個角度看，在產品開發的不同階段通常有不同的任務，由
不同的角色擔當，各個角色職責明確，泾渭分明，但同時又前後銜接，相互協調。
好的配置管理過程有助於規范各個角色的行為，同時又為角色之間的任務傳遞提供
無縫的接合，使整個開發團隊象一個交響樂隊一樣和諧而又錯雜地行進。
正因為配置管理過程直接連接產品開發過程、開發人員和最終產品，這些都
是項目主管人員所關注的重點，因此配置管理系統在軟件項目管理中也起著重要。
配置管理過程演化出的控制、報告功能可幫助項目經理更好地了解項目的進度、開
發人員的負荷、工作效率和產品質量狀況、交付日期等信息。同時配置管理過程所
規范的工作流程和明確的分工有利於管理者應付開發人員流動的困境，使新的成員
可以快速實現任務交接，盡量減少因人員流動而造成的損失。
1.3 配置管理方案的構成
配置管理過程對軟件開發有如此重要的影響，它的構造、實施過程也必定相
當復雜。不借助工具，純粹靠手工方式或只利用簡單的工具來實現配置管理是很難
做到滿意程度的，而且其中的繁瑣龐雜最終必定讓管理者一愁莫展。因此，實現配
置管理過程的通常做法是借助於專業化的配置管理工具，結合開發組織的實際情況
制訂出相應的配置管理規范，由開發人員在工作過程中依據規范，通過配置管理工
具來實現。在這整個過程中，由配置管理工具負責那些非智能的、可自動化的管理
過程，如身份角色驗證、修改軌跡記錄、版本控制等；由配置管理規范來控制那些
需要開發人員用智力去判斷的因素，如需求合理性和優先級判定、任務分工、產品
的結構定義、版本發行方案確定等等。配置管理工具的采用和配置管理規范的制訂
是緊密聯系的，二者構成了一個軟件開發機構的整體配置管理方案。這種方案是因
組織的差異和配置管理工具的差異而變化的。構造一個配置管理方案涉及到軟件開
發組織和開發過程的各個方面，是一個復雜的工程應該當作一個項目來做。本文試
圖給出一個構造配置管理方案的基本策略和主要步驟。
2 組建配置管理方案構造小組
構造或完善一個軟件開發組織的配置管理過程需要在構造初期花費較大的人
力物力。這種工作一般是由一個臨時組成的軟件配置管理過程構造小組來完成。這
個小組負責構造配置管理過程中的所有工作，包括了解本組織的現有開發、管理現
狀，選擇配置管理工具，制訂配置管理規范，安排試驗項目的實施，溝通部門間關
系，獲得管理者支持和開發人員的認同。
配置管理過程構造小組的成員應該包括：
? 小組負責人
其對整個構造過程負責。主要職責是協調與其它部門或與上級主管的關系，
監督工作進程，協調小組內部關系。
? 技術支持專家
其負責在技術、設備方面為本組提供支持和服務，並負責本同其它部門就技
術問題進行聯絡，如了解相關項目情況、開發環境、開發人員狀況等。
? 配置管理技術專家
其對配置管理過程的構造和配置管理工具十分熟悉。主要任務是指導配置管
理過程的構造，幫助制訂配置管理規章，負責對開發人員進行配置管理工具的培
訓。通常是配置管理工具提供商或專門的配置管理顧問機構的人員擔當此任。
? 配置管理系統用戶代表
他們是從將來要在實際的項目開發過程中使用該系統、遵照該過程的開發人
員中挑選出來的。他們負責從構造初期了解配置管理系統和規程，根據開發經驗協
助制訂、修改配置管理規程，並在試驗項目中擔任部分開發角色。這部分成員應包
括軟件開發項目經理、設計人員、編碼、測試和構造、發布人員。
該項目小組成立後，將按後述步驟開展配置管理過程的構造工作。
3 對目標機構進行了解、評估
“知已知彼，百戰不殆”。配置管理過程的構造過程也是如此，必須對相互
作用的雙方都有較透徹的了解才能達到預期的效果。因此首先要做的事情是調查了
解，既要了解目標機構（即將要采用該配置管理過程的軟件開發組織）的情況，又
要了解配置管理工具的情況。
目標機構的調查評估工作由配置管理技術專家領導，配置管理系統用戶代表
參與，提供基本信息，並由小組負責人協調，對相關部門人員進行深入調查獲得較
全面的數據。
對目標機構的了解、評估應從這幾個方面入手：人員、技術、工作流程、現
有項目和期望值。
3.1 人員評估
人員評估的目的是了解目標機構的員工對現有配置管理過程的評價和對采用
新工具、制訂新規范的態度，預測新的配置管理過程構造中的工作難點和可能遇到
的阻力。調查的方面包括：
該組織員工對引入新工具的反應，以前是否有過類似的償試。
該組織負責人對新工具、新流程的支持程度。
開發人員的素質、教育程度、溝通能力。
開發隊伍的穩定性。
該組織的溝通渠道是否通暢。
3.2 技術評估
對目標機構技術方面的的調查、評估將直接導致對工具的選擇。要了解的信
息有：
目標機構有哪些可用的計算資源。
在什麼軟硬件平台上進行開發。
是否存在資源瓶頸，是什麼。
現用什麼開發工具，用戶對該工具評價如何。
現用什麼網絡環境。
使用什麼編程語言。
目標平台是否與開發平台一致。
代碼更新程度如何，新編代碼、重用代碼和歷史代碼各占什麼比例。
3.3 現有流程評估
對目標組織現有工作流程的評估直接影響新的配置管理流程和規章的制訂。
調查的方面是：
現有流程的成熟性、適用性和執行情況。
現有流程是否能進一步提高自動化程度。
現用什麼開發模型。
對分析、設計、編碼、測試、產品管理等過程是否有嚴格的成文規范，如何
保證該規范的執行。
開發流程中的哪些質量控制信息被收集，如何使用。
3.4 項目評估
配置管理系統對正在開發的產品、正在進行的項目有直接的影響，因此對即
將納入管理的項目應有充分的了解。了解的方面有：
項目的平均工期（人月）。
項目的組織方式，是主程序員制還是開發小組制，按深度結構還是按廣度結
構組織。
項目的產品規模（功能模塊數、源碼行數）。
項目開發支持狀況，是否有專門的開發環境、開發工具和配置管理等方面的
支持人員。
3.5 期望值評估
對目標機構的開發、管理人員對新系統的期望值的了解有利於對症下藥，解
決其當前緊要問題，提高對新系統的信心。調查的方面包括：
對當前本組織的生產率和產品質量的滿意程度，期望有怎樣的提高。
對現有流程的評價，現有流程中哪個環節希望改進或加強。
期望增減哪些文檔或規則。
期望等到什麼樣的通信交流方式，現有方式的優缺點是什麼。
期望收集哪些新的開發度量數據或簡化哪些數據。
4 配置管理工具及其提供商評估
通過對目標組織的評估，了解該組織的現狀和需求後，就需要選擇適合該組
織的配置管理工具。市場上現有的配置管理工具不下數十種，它們各有所長，在功
能，性能等方面有較大的差別，只有經過仔細地對產品及其提供商進行分析評估，
核對目標機構的需求，才能挑選出合適的工具，實現一個理想的配置管理過程。
這種評估可從三個方面進行：配置管理工具的評估、供應商評估和其它用戶
使用經驗的評估。
4.1 配置管理工具評估
對工具的評估應側重於功能的適用性，而不應一味強調功能的全面性。產品
評估應了解如下問題：
該產品的哪一方面功能可解決目標組織的當前問題滿足該組織在配置管理上
的需求。
該產品在目標機構的峰值負荷下的運行效率將如何。
該產品對並發使用的支持情況如何
該產品與現有系統、工具、流程、環境的兼容性如何。
該產品的成熟性和穩定性如何。
該產品是否易學易用。
該產品的購買、安裝、實施、維護費用是否可以接受。
4.2 供應商評估
供應商的實力和它所能提供的服務和支持對配置管理系統的實施至關重要。
因為配置管理工具不象其它的工具那樣，只要安裝完成後按照使用手冊和在線幫助
就能使用，而是必須在系統之外有一系列的操作、管理規范，有一套完整的方案。
這些些必須在系統提供者或顧問機構的幫助下才能制訂、實施。因此，系統提供商
對配置管理過程的實現有重要影響。對供應商的評估包括：
供應商在相應行業的從業時長。
該產品是否是該供應商的主導產品。
該供應商的年銷售額。
供應商在五年之內的穩定情況。
該供應商是否有專業化的客戶支持隊伍。
是否提供安裝、用戶培訓等服務。
供應商的聲望、信譽如何。
供應商的支持人員在地理位置上是否與目標機構鄰近。
另外，通過了解同一產品的其它用戶對該產品的評價可以對該產品和供應商
有較為客觀、綜合的認識。這種評價可從所知的用戶組、專業會議、配置管理工具
公告板等途徑獲得。
5 制訂實施計劃
經過對目標機構和選用工具的評估，工作小組可以制訂出一份完整的工作計
劃作為下一階段的行動綱要，同時也是向上級主管匯報，取得支持的有力佐證。
工作計劃由如下部分組成：
? 必要性和影響因素
結合目標機構的開發過程組織和配置管理現狀，論證構造或完善配置管理過
程的必要性；根據所選配置管理工具的功能特性和供應商的實施支持，闡明新的配
置管理系統可對目標機構的開發和管理工作帶來改進和驅動。另外，對該配置管理
系統和相應的配置管理過程對現有的人員、工序和管理等方面可能帶來的影響作出
適當的預測，以便減小將來實施時可能遇到的阻力。
? 配置管理目標和配置管理過程的構造成功標准
對正待構建的新的配置管理過程制訂出一個較為長遠的目標，即要達到哪種
控制程度，加強哪些方面的管理，是否按照相關的國家或國際標准實施，達到何種
級別等等。
另外，對構造配置管理過程的工作本身，如前所述應當作一個項目來做，因
此也必須制訂一個明確的完成標准。該標准應該在本小組內部統一並獲得上級主管
認可。
? 人員組織和分工
進一步明確工作小組的組織成員和成員關系，為每個成員分派相應的任務和
職責。這些任務應該具體、細化到可操作的程度，如張三負責與某部門接洽，了解
原有某一管理規范，李四負責試驗環境的准備工作等等。
? 進度計劃
羅列出構造過程中所要解決的問題，設置裡程碑。
? 風險管理
預測構造過程中可能遇到的外在困難因素，如硬件短缺、平台差異、與相關
部門沖突、試驗項目的特殊性等等。為這些風險因素設計出降低或規避風險的方
法。
6 定義配置管理流程
配置管理流程是軟件開發機構進行配置管理的依據，也是配置管理構造工作
小組的最重要的工作成果。配置管理流程規定開發過程中需要做哪些配置管理方面
的工作，由誰做、如何做。前兩個問題有較為通用的答案，在後文將會涉及，第三
個問題則必須根據目標機構的具體情況解決。
制訂配置管理流程的方法是：通過對目標機構的調查、評估，定義現有的配
置管理流程，由配置管理技術專家對它進一步分析，結合常規的配置管理方法制訂
出新的流程。之後，依據選定的配置管理工具的功能，將新流程中可自動化的環節
交由配置管理工具處理，其它環節由新制訂的配置管理規范控制。
除了制訂配置管理規范外，該小組還應制訂出適合目標機構的配置管理基本
章程。該章程應包括配置管理部門的設立、該部門的責能（通常是負責監督配置管
理規范的執行情況，對配置規范進行完善，並擔當日常的內部配置管理過程支持任
務），定義配置管理過程與開發過程的協調關系，以及各開發階段的開發人員構
成、在配置管理流程中的責任劃分等等。
一般說來，配置管理包括四個方面的活動：配置項標志，配置項控制（修改
控制），配置狀態報告和配置審核。配置管理規范的制訂也應按這四個方面內容進
行。每一個方面要考慮的問題是：
? 配置項標志
制訂文檔或文件編號、標記體系。
定義文檔和文件之間的聯系。
確定受控的配置項的取捨，如軟件源碼、硬件描述文件、中間文件、目標文
件、測試方案、系統數據等等。
確定產品版本、基線的標志體系。
確定庫程序的標志和管理機制。
? 配置項控制
確定產品的版本的演化策略，規定何時、何人創建新的基線，如何創建。
確定修改請求控制機構（CCB－Change Control Board） 的人員組成、職
能、工作程序。
確定修改請求的處理流程和終止條件。
確定修改請求處理過程中各開發人員的職能。
確定修改請求和所生成的結果的對應機制。
確定文檔的修改方式。
確定配置項的提取方式。
? 配置狀態報告
定義報告的內容、形式、提交方式。
確定產品的發行事宜，包括發行時間如何確定、發行說明的生成發布方式、
發行方式等。
? 配置審核
確定審核的執行人員、執行時機，審核的內容和方式。
確定發現問題後的處理方法。
7 試驗項目的實施
這一階段的任務是選取目標機構中的一個現有項目，按既定的配置管理流程
去進行開發和配置管理工作。這種試驗的目的是在一定風險范圍內，通過實地運作
來確定所選配置管理工具、所制訂的配置管理規范是否能滿足目標機構的需要。要
做的工作有：
? 選定試驗項目
該項目應該具有一定的復雜性，但又有較強的獨立性，不會對目標機構的關
鍵項目造成重要影響。
? 選定試驗組成員
通常應包括構造小組的部分成員和該項目原有的成員。
? 定義試驗成功的標准和試驗時間表
應以配置管理流程和項目開發管理過程的協同程度和總體工作效率為依據。
? 人員培訓
包括配置管理工具培訓和配置管理規范培訓。
? 配置管理工具的安裝和項目環境的搭建
包括將歷史代碼導入到新系統中，將原有配置管理信息轉換成新系統的形
成，置於新系統控制之下；搭建項目所需的軟硬環境等。
? 開發過程
按新的配置管理流程進行試驗項目的開發，及時收集項目開發人員的反饋信
息。
? 調整配置管理流程
根據項目的進行情況和開發人員的反饋信息，找出新配置管理流程的不足，
及時調整改進。
8 全面實施
經過試驗項目證實、校正後的配置管理流程就可以在目標機構的各個項目、
各個相關工作環節中去應用、實施，最終使配置管理過程日常化、規范化。全面實
施過程主要由配置管理部門根據新的配置管理流程來指導。配置管理過程構造小組
的作用趨於淡化，主要起監督和支持作用。該小組在全面實施過程中逐步解散，小
組中部分成員可轉移到配置管理部門中去。
全面實施階段的任務有：
組建或完善配置管理部門，並完成配置管理流程的移交。
由配置管理部門制訂各個項目的配置管理實施計劃。
進行全組織范圍的配置管理系統和規則的培訓。
幫助各個開發項目向新流程轉移。
進行日常的監督、抽查、評估和規范的完善工作。
10 結語
配置管理過程的建立是一個復雜而漫長的過程，因為它受軟件開發機構的許
多方面的影響，包括技術、設備、項目、制度、人員、文化等因素。就象其它任何
新事物的出現一樣，在一個機構內剛剛建立的配置管理過程必然會受到各方面的挑
戰和考驗，因此需要有一個適應、融合的過程。另外，配置管理過程的建立也不是
一件一勞永逸的事情，不同機構、同一機構在不同的發展階段或不同的項目中會有
不同的配置管理細節，這些都需要配置管理部門在長期工作過程中對配置管理過程
不斷調節、充實、完善。
參考文獻
1. ISO 10007:1995 Quality management – Guidelines for configuration
management
2. ISO 9000-3:1997 Quality management and quality assurance standards –
Part 3: Guidelines for the application of ISO 9001 to the
development, supply and maintenance of software
3. Susan A. Dart, Adopting An Automated Configuration Management
Solution, Conference of STC'94, 12 April, 1994, Utah
4. Nadine M. Bounds, Susan Dart, CM Plans: The Beginning to Your CM
Solution,
www.sei.cou.edu/legacy/scm/papers/CM_Plans/CMPlans.MasterToC.html
5. Julie Kingsbury, Adopting SCM Technology,
www.stsc.hill.af.mil/crosstalk/1996/mar/adopting.asp
6. Kimberly S. Oakes, etc, Guide to CASE Adoption, Technichal Report
CMU/SEI-92-TR-15
7. Susan Dart, Spectrum of Functionality in Configuration Management
Systems, Technical Report CMU/SEI-90-TR-11
8. Peter Feiler, Grace Downey, Transaction-Oriented Configuration
Management: A Case Study, Technical Report CMU/SEI-90-TR-23
9. Anil K. Midha, Software Configuration Management for the 21st Century,
Bell Labs Technical Journal, Winter 1997
