軟體專案的配置管理

1. 軟體專案的配置管理

2. 目錄 1 軟體配置及其管理的概念 2 配置管理活動和流程 3 配置管理需求 4 版本管理 5 變更管理 6 配置狀態監測與報告 7 基於配置管理的軟體專案管理 8 配置管理的技術手段和工具

3. 目錄 1 軟體配置及其管理的概念 2 配置管理活動和流程 3 配置管理需求 4 版本管理 5 變更管理 6 配置狀態監測與報告 7 基於配置管理的軟體專案管理 8 配置管理的技術手段和工具

4. 1 軟體配置及其管理的概念 1.1 CMM2的配置管理概念 1.2 IEEE的配置管理定義 1.3 配置管理概述 1.4 配置管理活動的作用

5. 配置的概念 • 配置的概念來自硬體 • 軟件工程師是如何處理介面的？ • 廣而言之： • 軟體的變化可以發生在一秒鐘內 • 軟件的變化可以發生在每一秒鐘 • 軟件開發過程下一秒鐘是不確定的 • 情況將會怎樣？怎麼辦？

6. 軟體專案開發管理的新需求 • 你在一家小公司做軟體工程師，開始的時候，你只有一個人，配了2個助手。你們研究了一種演算法（例如：圖像壓縮、資料加密等），編寫了一個實現模組。有一天老闆看到了你的演示，認為很有市場潛力，可以結合進公司正在給某行業使用者正在準備開發的系統中，成為該系統的核心技術或一個別人沒有的賣點。 • 下一周，你的隊伍增加到14（你的老闆準備就此豪賭一把了），與你3個人的小組不同的是，公司從其他部門為你配備了系統分析師，還有文檔編制員、測試員。你的核心模組已經被大量的使用者功能所包裝，成為一個行業應用系統，並開始給使用者試用，這是你的系統的第一版。 • 3個月後，公司決定把系統升級到第二版，除增加了許多新的功能外，公司決定支持多平臺，同時，為了提高系統的性能和效率，準備採用協力廠商廠家的中介軟體，取代自己做的介面。第一版的缺陷修改，也要反映到第二版中。 • 第2版經過2個多月的開發，最終推向了市場。公司的這個產品不但被使用者所歡迎，也被一家大公司所看中（就像IBM收購了Lotus和Rational、Informix一樣），你們的產品，正好可以填補這家大公司產品線的空缺，你所在的公司被這家公司買去了。

7. 公司為你的專案組派來了產品經理、專案經理。公司決定這個產品的測試，由公司總部獨立的測試部門承擔。同時，公司決定把專案組增加到50人，其中有20多人並不在你所在的城市。在新公司裡，產品管理、專案管理、測試、品質等等，都與你過去的環境和做法不同，特別不同的是，公司準備開發的第3版系統與公司原有的產品要進行融合，使他們看上去是一家出來的不同的兄弟和姐妹。公司為你的專案組派來了產品經理、專案經理。公司決定這個產品的測試，由公司總部獨立的測試部門承擔。同時，公司決定把專案組增加到50人，其中有20多人並不在你所在的城市。在新公司裡，產品管理、專案管理、測試、品質等等，都與你過去的環境和做法不同，特別不同的是，公司準備開發的第3版系統與公司原有的產品要進行融合，使他們看上去是一家出來的不同的兄弟和姐妹。 與軟體的第1版、第2版相比，你的專案管理有什麼不同？ 隨著這個產品的演變，專案發生了四個變化： （1）系統的複雜性發生了很大變化； （2）用於開發該系統的專案環境發生了很大變化； （3）在不同的專案生命週期內，專案控制本身的要求和力度發生了很大變化； （4）由於組織的變化，管理流程、人員、方式發生了很大變化。 前二類變化要求專案的組織和管理適應系統擴展的需要，後二種變化則要求專案管理具有適應性和靈活性。

8. 缺乏管理所造成的問題 • 軟體發展人員之間缺乏必要的交流 • 產品升級和維護所必需的程式和文檔非常混亂 • 開發過程中的人員流動經常發生 • 因管理不善致使未經測試的軟體加入到產品中 • 項目開發狀態不清楚 • 軟件生產達不到規模化

9. 軟體配置管理SCM（Software Configuration Management） 軟體配置管理（SCM）是指在開發過程中各階段，管理 電腦程式演變的學科，它作為軟體工程的關鍵元素，已經成為軟體發展和維護的重要組成部分…… SCM提供了結構化的，有序化的，產品化的管理軟體工程的方法。它涵蓋了軟體生命週期的所有領域並影響所有資料和過程。 • 配置管理是指用於控制系統一系列變化的學科。 • 通過一系列技術，方法和手段來維護產品的歷史，鑒 別和定位產品獨有的版本，並在產品的開發和發佈階段 控制變化。 • 通過有序管理和減少重複性工作，配置管理保證了生 產的品質和效率。

10. 我們知道，在軟體建立時，變更是不可避免的，而變更加劇了項目中軟體發展者之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現並向其他有關人員報告變更。我們知道，在軟體建立時，變更是不可避免的，而變更加劇了項目中軟體發展者之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現並向其他有關人員報告變更。 因此，從某種角度講，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小並最有效地提高生產效率。 SCM通過以下方法，強化軟體的可靠性和品質： （1）提供用於識別和控制文檔、代碼、介面、資料庫的結構框架，適用於軟體發展生命週期的所有階段； （2）全面支撐某一特定開發及維護工作方法，能夠適應各種類型的需求、標準、政策、組織機構以及相關的管理策略； （3）針對特定的基線狀態、變更控制、測試、發佈版本或審查活動，生成相應的管理資訊和產品資訊。 因此，從某種意義上講，SCM本質上是變更的管理。 SCM使軟體產品和過程的變更變為受控的和可預見的，它要求並在適當的工具支持下能夠做到這樣幾點： （1）誰做的變更？ （2）軟體有什麼變更？ （3）什麼時間做的變更？ （4）為何要變更？

11. 軟體專案的配置管理 • 隨著電腦軟體的發展，軟體發展已由最初的“程式設計階段”經歷了“軟體系統階段”進而演變為後來的“軟體工程階段”，軟體的複雜性日益增大。此時，如果仍然把軟體看成一個單一的個體，就無法解決所面臨的問題，於是配置的概念逐漸引入軟體領域，人們越來越重視軟體配置的管理工作。 • 不懂軟體專案的配置管理，就不懂軟體發展管理 • 不對軟體專案進行配置管理，就沒有進行軟體專案開發管理

12. 1.1 CMM2的配置管理概念 軟體配置管理是CMM2中6個關鍵過程域的第6個關鍵域。CMM2認為，SCM 的目的是為了建立和維護軟體發展過程中各種製品的完整性和一致性，包括以下內容： • 對軟件產品配置的標誌和識別 • 系統地控制對處於配置管理下的各種軟體製品的修改和更新 • 維護軟件開發過程中的各種製品的一致性和可跟蹤性

13. SCM 的目標 • 目標1:軟體配置管理活動被定義和計畫 • 目標2:軟體發展過程中的製品被識別、控制和管理 • 目標3:對於處於配置管理下的軟體製品的修改被控制 • 目標4:與軟體製品相關的專案組和成員應該被通知製品的目前狀態和被修改的資訊 從對配置目的的定義可以看出，CMM2的配置管理應包括這樣一些活動：標識給定時間點的軟體配置（即所選擇的工作產品及其描述），系統地控制這些配置的更改，並在軟體生命週期中保持這些配置的完整性和可跟蹤性。 CMM2認為，受控於配置管理的工作產品，包括交付給使用者的軟體產品（如：代碼等），以及生成軟體產品所需要的有關項（如：專案管理檔）。 CMM2的配置管理活動最主要的內容是：建立軟體基線庫，該庫存儲開發的軟體基線。通過軟體配置管理的更改控制和配置審核功能，系統地控制基線變更和由軟體基線庫生成的軟體產品版本。

14. 要達到 CMM 規定的 SCM要求所需具備的能力 • 具有對軟體基線產品有管理許可權的組織已經建立，例如：軟體配置管理委員會； • 協調和實現軟體配置管理的組織已經建立； • 為進行軟體配置管理所需要的各項資源已經分配； • 軟件配置管理組織裡的成員已經接受了軟體配置目標、流程、方法方面的培訓； • 軟件專案組或是其他的相關的部門經過培訓，可以執行他們的軟體配置管理活動；

15. CMM 中對SCM 規定的活動 • 根據文檔化的流程，專案軟體配置管理計畫已準備完畢； • 文檔化的已獲批准的軟體配置管理計畫可用作以後軟體配置管理活動的基礎； • 軟件配置管理庫已經創建，並可用作進入基線的軟體製品的存貯庫； • 處於軟件配置管理下的軟體製品被標誌和識別； • 對於配置項的變更請求和問題報告被初始化、計畫、評審、批准並根據文化化的流程對其進行跟蹤；

16. CMM 中對SCM 規定的活動 • 對於進入基線的製品的修改必須遵循文檔化的流程； • 發布的產品必須從軟體配置庫中取出，並且產品發佈的流程須依照文檔化的流程和規定； • 根據文檔化的流程和規定，軟體配置項的狀態被記錄和跟蹤； • 記錄軟件配置管理活動和軟體基線內容的報告被建立，並通知受到影響的專案組和個人； • 根據文檔化的流程進行軟體製品基線的評審；

17. 組織規定和相關責任 • 專案級配置管理 • 項目配置經理(Project Configuration Manager) 與軟體配置管理計畫 • 變更控制委員會(Change Control Board) • 組織級配置管理 • 組織配置管理庫(Organizational Configuration Management Cell) • 負責專案完成後的軟體配置管理活動 • 管理組織級的文檔

18. 1.2 IEEE的配置管理定義 IEEE標準729-1983就配置管理的內容進行了規範的定義：（1）標識：識別產品的結構、產品的構件及其類型，為其分配唯一的識別字，並以某種形式提供對它們的存取。（2）控制：通過建立產品基線，控制軟體產品的發佈和在整個軟體生命週期中對軟體產品的修改。例如，它將解決哪些修改會在該產品的最新版本中實現的問題。（3）狀態統計：記錄並報告構件和修改請求的狀態，並收集關於產品構件的重要統計資訊。例如，它將解決修改這個錯誤會影響多少個檔的問題。（4）審計和審查：確認產品的完整性並維護構件間的一致性，即確保產品是一個嚴格定義的構件集合。例如，它將解決目前發佈的產品所用的檔的版本是否正確的問題。（5）生產：對產品的生產進行優化管理。它將解決最新發佈的產品應由哪些版本的文件和工具來生成的問題。（6）過程管理：確保軟體組織的規程、方針和軟體週期得以正確貫徹執行。它將解決要交付給使用者的產品是否經過測試和品質檢查的問題。（7）小組協作：控制開發統一產品的多個開發人員之間的協作。例如，它將解決是否所有本地程式師所做的修改都已被加入到新版本的產品中的問題。

19. 1.3 配置管理功能概述 CMM2的定義比較抽象，IEEE的定義就比較具體。結合各體系的定義和要求，我們下面具體來討論配置管理的概念。

20. SCM的四大功能領域 配置標識或者又稱為配置需求，包括標識軟體系統的結構，標識獨立部件，並使它們是可訪問的。配置標識的目的，是在整個生命週期中標識系統各部件並提供對軟體過程及其軟體產品的跟蹤能力。它回答：什麼是受控的？ 配置變更控制包括在軟體生命週期中控制軟體產品的發佈和變更，目的是建立確保軟體產品品質的機制。它回答：受控產品怎樣變更？誰控制變更？何時接受，恢復，驗證變更？ 配置狀態統計包括記錄和報告變更過程，目標是不間斷記錄所有基線項的狀態和歷史，並進行維護，它解決以下問題：系統已經做了什麼變更？此問題將會對多少個文件產生影響？配置變更控制是針對軟體產品，狀態統計針對軟體過程。因此，二者的統一就是對軟體發展（產品、過程）的變更控制。 配置審核將驗證軟件產品的構造是否符合需求、標準、或合同的要求，目的是根據SCM的過程和程式，驗證所有的軟體產品已經產生並有正確標識和描述，所有的變更需求都已解決。它回答：系統和需求是否吻合？是否所有變更都是在版本控制下？

21. SCM的三個應用層次 SCM從應用層次上可以從低到高分為三級：版本控制、以開發者為中心、過程驅動。 版本控制主要應用于個人獨立開發或小組開發，它可以控制任何檔的版本、實現分支和歸併功能、進行文本比較、標記注釋和版本報告資訊，主要工具有MS的Visual SourceSafe及Intersolv PVCS。 以開發者為中心主要應用于部門級開發，它可用於軟體維護、不斷增加的開發任務、並行開發、QA及測試，它面向大型團隊、利於交流、能最大限度地利用人力資源，主要工具為Rational ClearCase及MKS Source Integrity。 過程驅動主要使用于企業級開發，著重解決新的工具引入、IT審核、管理報告、複雜的生命週期、應用工具包、集成解決方案、資料庫等問題，實現真正規範的團隊開發，主要工具為Platinum Technology CCC/Harvest。

22. SCM 中的專業術語 • 配置(Configuration)與配置項(Configuration Item) • 在軟體發展過程中生成各種製品的總和叫做這個專案的軟體配置 [Roger S. Pressman, 1997] • 電腦程式，包括原始程式碼和可執行程式 • 與計算機程式相對應的各種文檔 • 計算機資料，包括電腦程式中包含的資料和系統初始化資料

23. SCM 中的專業術語 • 基線 • 專案開發過程的製品經過正式評審並被相關人員一致同意，可以作為以後專案開發的基礎。對已經確定為基線的製品的修改必須要通過正式的變更控制流程。 • 在軟體工程環境中，基線是指在軟體發展過程中的里程碑，這些里程碑的標誌是一項或多項經過正式的技術評審並一致認同的軟體製品的提交。

24. SCM 中的專業術語 • 配置資料庫（軟體製品基線庫） • 專案建立和訪問軟體製品庫，這個製品庫主要用來對保存配置項和一些與軟體配置管理相關的記錄。 • 目前比較好的配置管理工具：Clearcase (Rational), Notes/Domino (Lotus), PVCS (Merant) and VSS (Microsoft).

25. Project Root Directory Code DOC Project Planning Phase Documents Requirements Analysis Phase Documents Design Phase Documents Code, Unit Test & Integration Phase Documents System Test Phase Documents DATA A B B B B Phase Deliverables Phase Deliverables Product Software Test Software Product Software Related Test Software Related Source Code Objective Code Executive Code 配置管理庫(1) • 基線庫的結構(VOB)

26. 配置管理庫 配置管理庫的具體實現——專案檔案夾 • 項目檔件是專案開發過程中由專案組創建和維護的製品歸檔庫。 • 軟件配置管理負責管理和控制專案檔案夾，並對資料夾中的內容進行評審； • 項目經理負責監督專案的軟體配置管理執行； • 軟件品質工程師負責對專案檔案夾的內容進行評審；

27. 配置管理庫 • 專案檔案夾的內容 • 項目開發過程中的所有資訊，包括文檔、工作製品和各種週報、月報、評審等； • 與外部的交流資訊，例如與客戶、協力廠商的通訊交流記錄等； • 其他交流會議記錄，例如：重要的Email，傳真， 信件等；

28. 配置管理庫 許可權管理 • 專案組內部的許可權管理與分配 • 對其他專案組的開放許可權管理與分配 • 對其他用戶或是協力廠商的許可權管理與分配

29. 1.4 配置管理活動的作用 • 配置管理與品質管制 在品質體系的諸多支援活動中，配置管理處在支援活動的中心位置。品質管制雖然也有過程的驗證，但配置管理只要定義的配置項夠細，則它可以管理軟體發展的全過程，細到每一個模組、每一個文檔、每一條工程記錄的變化。 因此，配置管理從基礎層開始，有機地把其它支持活動結合起來，形成一個整體，相互促進，相互影響，有力地保證了品質體系的實施。

30. 配置管理給專案組帶來的好處 （1）節約費用縮短開發週期減少施工費用 （2）有利於知識庫的建立 代碼物件程式庫 業務及經驗庫 （3）規範管理量化工作量考核規範測試 （4）加強協調與溝通

31. 目錄 1 軟體配置及其管理的概念 2 配置管理活動和流程 3 配置管理需求 4 版本管理 5 變更管理 6 配置狀態監測與報告 7 基於配置管理的軟體專案管理 8 配置管理的技術手段和工具

32. 2 配置管理活動和流程 2.1 主要配置管理活動 2.2 專案經理的配置管理流程

33. 2.1 主要配置管理活動 • 標誌配置項 • 變更控制 • 版本控制 • 評審 • 統計 • 軟體編譯、連接和發放管理

34. RUP描述的配置管理的主要活動如下圖所示： 對於一個軟體專案組來說，開展一個專案組的配置管理，大致可以分為以下步驟： （1）擬訂專案的配置管理計畫；（2）創建專案的配置管理環境；（3）進行專案的配置管理活動，包括：標識配置項；管理基線和發佈活動；監測與報告配置狀態；管理變更請求。 （1）和（2）可以看成配置管理的準備，（3）是配置管理的具體實施。配置管理的具體實施，在RUP定義為四個管理活動。 對於一個軟體專案組來說，開展一個專案組的配置管理，大致可以分為以下步驟：

35. 配置項（Software Configuration Item，SCI）識別 對於配置項，可以給出一個比較簡單的定義，既軟體過程的輸出資訊可以分為三個主要類別： （1）電腦程式（原始程式碼和可執行程式） （2）描述電腦程式的文檔（針對技術開發者和用戶） （3）資料（包含在程式內部或外部）。 這些項包含了所有在軟體過程中產生的資訊，總稱為軟體配置項。” 在CMM2中，除上述3個配置項以外，還包括項目管理的有關檔、資訊記錄等。 由此可見，配置項的識別是配置管理活動的基礎，也是制定配置管理計畫的重要內容。

36. 配置項（Software Configuration Item，SCI）識別 軟體配置管理認為軟體的開發過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟體配置管理引入了“基線（Base Line）”這一概念。 IEEE對基線的定義是這樣的：“已經正式通過審核批准的某規約或產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程改變。” 所以，根據這個定義，我們在軟體的開發流程中，也可以把所有需要加以控制的配置項分為基線配置項和非基線配置項兩類，例如：基線配置項可能包括所有的設計文檔和來源程式等；非基線配置項可能包括專案的各類計畫和報告等。 有關配置項的內容，我們將在後面，專門花一節的篇幅，進行討論。

37. 配置項的標識和控制 所有配置項都應按照相關規定統一編號，按照相應的範本生成，並在文檔中的規定章節（部分）記錄物件的標識資訊。在引入軟體配置管理工具進行管理後，這些配置項都應以一定的目錄結構保存在配置庫中。 所有配置項的操作許可權應由配置管理員嚴格管理，基本原則是：基線配置項向軟體發展人員開放讀取許可權；非基線配置項向專案經理、配置控制委員會及相關人員開放。

38. 工作空間管理 在引入了軟體配置管理工具之後，所有開發人員都會被要求把工作成果存放到由軟體配置管理工具所管理的配置庫（存儲池）中去，或是直接工作在軟體配置管理工具提供的環境之下（根據配置管理構架提供的控制方式不同而不同）。 每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上。 比較理想的情況是把整個配置庫視為一個統一的工作空間，然後再根據需要把它劃分為個人（私有）、團隊（集成）和全組（公共）這三類工作空間（分支），從而更好的支援將來可能出現的並行開發的需求。

39. 版本控制 版本控制是軟體配置管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本資訊以外，為了配合軟體發展流程的各個階段，我們還需要定義、收集一些中繼資料來記錄版本的輔助資訊和規範開發流程，並為今後對軟體過程的度量做好準備。當然如果選用的工具支援的話，這些輔助資料將能直接統計出過程資料，從而方便我們軟體過程改進（Software Process Improvement，SPI）活動的進行。 對於配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設置相應的存取權限。一般來說，對於基線版本之前的各個版本都應處於被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。

40. 變更控制 變更管理的一般流程是： （1）（獲得）提出變更請求； （2）由CCB審核並決定是否批准； （3）（被接受）分配請求，修改人員提取配置項，進行修改； （4）複審變化； （5）提交修改後的配置項； （6）建立測試基線並測試； （7）重建軟體的適當版本； （8）複審（審計）所有配置項的變化； （9）發佈新版本。 在這樣的流程中，配置管理員通過軟體配置管理工具來進行存取控制和同步控制，而這兩種控制則是建立在前面所描述的版本控制和分支策略的基礎上的。

41. 狀態報告 配置狀態報告應該包括下列主要內容： (1)配置庫結構和相關說明； (2)開發起始基線的構成； (3)當前基線位置及狀態； (4)各基線配置項集成分支的情況； (5)各私有開發分支類型的分佈情況； (6)關鍵元素的版本演進記錄； (7)其它應報告的事項。

42. 配置審計 配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作為正式的技術複審的一部分，但當軟體配置管理是一個正式的活動時，該活動由SQA人員單獨執行。 總之，軟體配置管理的物件是軟體研發活動中的全部開發資產。所有這一切都應作為配置項納入管理計畫統一進行管理，從而能夠保證及時的對所有軟體發展資源進行維護和集成。因此，軟體配置管理的主要任務也就歸結為以下幾條： （1）制定專案的配置計畫； （2）對配置項進行標識； （3）對配置項進行版本控制； （4）對配置項進行變更控制； （5）定期進行配置審計； （6）向相關人員報告配置的狀態。

43. 2.2 專案經理的配置管理流程 專案經理的工作是： （1）確定專案配置管理策略 （2）確定用於控制產品變更的策略和流程 （3）在配置管理計畫（是軟體發展計畫的一部分）中記錄此資訊

44. 配置管理策略 軟體配置管理策略是指能夠確定、保護和報告已經批准用於專案中的工件的能力。通過正確的標注來實現確定操作。對專案工件的保護是通過歸檔、建立基線和報告等操作而得以實現的。 使用標準的、已記錄下來的變更控制流程的目的是：確保項目中所做的變更保持一致，並將產品的狀態、對其所做的變更以及這些變更所耗費的成本及對時間表的影響通知給有關的涉眾。 軟體配置管理計畫說明在產品/專案生命週期中要執行的所有與配置管理相關的活動。它記錄如何計畫、實施、控制和組織與產品相關的配置管理活動。

45. 配備人員 配置管理人員的選擇和配備，是軟體專案經理最主要的工作。在一個比較理想的軟體發展團隊中，需要哪些角色呢？ 負責軟體專案組的專案經理 負責SCM計畫和策略的配置經理 負責軟體產品開發與維護的軟體工程人員 負責驗證產品正確性的測試人員 負責確保產品高品質的品質保證經理 使用產品的使用者。

46. 配置經理 配置經理的目標是確保用來建立、變更及編碼測試的計畫和策略得以貫徹執行，同時使有關專案的資訊容易獲得。 為了對編碼更改形成控制，配置經理引入規範的請求變更的機制，評估更改的機制（通過變更控制機構CCB，由它負責批准對軟體系統的變更），和批准變更的機制。 配置經理負責為工程人員創建任務單，交由項目經理對任務進行分配，創建項目的框架。同時，配置經理還收集軟體系統中構件的相關資料，比如說用以判斷系統中出現問題的構件的資訊。

47. 目錄 1 軟體配置及其管理的概念 2 配置管理活動和流程 3 配置管理需求 4 版本管理 5 變更管理 6 配置狀態監測與報告 7 基於配置管理的軟體專案管理 8 配置管理的技術手段和工具

48. 3 配置管理需求 3.1 配置管理的物件 3.2 最基本的配置管理項——文檔 3.3 UCM目錄結構下的配置管理物件

49. 3.1 配置管理物件 • 配置管理的第一個基本活動是配置標識，通俗地講，也就是查詢、識別和確定配置管理物件——配置項。在生產的軟體產品和軟體的生產過程中，那些是配置管理的物件呢？ • 配置管理物件呈現為一種層次結構，因此，為了標識配置管理的物件，我們需要對軟體系統進行分解： 目前，用於分解軟體系統的術語有多種多樣，沒有被標準化。 • 1989年Humphery定義了5個層次：系統、子系統、產品、構件和模組。 • 1991年Whitgift定義了3個層次：系統、子系統和元素。 • IEEE定義了3個層次：電腦配置項、電腦軟體構件和電腦軟體單元。 • RUP定義了4個層次：系統、實施（或構件）子系統、構件和檔（RUP5.5 1999）。

50. 配置管理物件 • 在RUP的概念裡，最底層的元素是處於版本控制下的檔和目錄，構件的層次要高於元素（檔和目錄），構件把元素組織起來。一個版本控制的構件是一個具體的物理的物件，就是一個根目錄。這個根目錄，以及從根目錄下所屬的所有目錄和檔，是系統的一個子系統。大的系統有多個根目錄（子系統），小系統則可能只有一個根目錄。 • 產品目錄結構為所有可具有版本號的、與產品相關的工件提供邏輯嵌套的預留位置。工件是開發流程生命週期的結果，用於開發整個系統的各組成部分（構件）。