四、我公司的實際應用
在一個通信軟件項目中，我公司采用了UCM來進行變更管理，至今已有近一年時間。所用的ClearCase和ClearQuest的版本為2001A.04.00。由于UCM的簡單易用，開發人員只用了幾天就掌握了使用方法，并且一直較為穩定地在運用。以下就UCM中的各個步驟，介紹一下在此項目中的實際應用。
1. 制定配置管理計劃
在建立UCM項目之前，首先制定了一個詳細的配置管理計劃。該計劃確定ClearCase網路的構成，ClearQuest數據庫的結構，依軟件系統架構定義所需各組件(vob),制定UCM項目的策略，等等。 
圖4
ClearCase網路的構成如圖4所示，名為LICENSE的電腦作為ClearCase和Suite的License Server，名為PDC3RASRV的電腦作為ClearCase之VOB/VIEW Server及Registry Server，名為VVTSERVE的電腦存儲ClearQuest Schema Repository Database和User Database(采用SQL Server 7.0)。
ClearQuest之Schema是基于Enterprise,并作了一些定制。
2. 建立項目
首先用VOB Creation Wizard創建PVOB以及作為UCM Component的各個vob, 然后在ClearCase Project Explorer中創建UCM項目，設定該項目采用ClearQuest UCM集成(ClearQuest數據庫已建立)。
圖5為該UCM項目之UCM Component示意。
圖5
3. 加入項目
開發者在ClearCase Explorer中，用Join Project精靈來加入到此UCM項目。每個開發者創建一個自己的開發流，一個開發視圖(采用快照視圖),一個項目集成視圖(采用動態視圖)。
4. 新增，分配任務
當有功能和設計變更要求時，項目經理在ClearQuest中新建變更需求記錄，然后由開發團隊或開發負責人對每一變更需求記錄，分析需要有哪些開發者做哪些具體改動，然后由開發負責人在ClearQuest中新建對應到此變更需求記錄的一個或多個BaseCMActivity,并分配給相關開發者。相關開發者在ClearCase Explorer之My Activities中，就可看到自己要處理的變更。 當測試人員發現缺陷時，在ClearQuest中新建缺陷記錄，開發負責人經分析后，將此缺陷分配給相關開發者。相關開發者在ClearCase Explorer之My Activities中，就可看到自己要解決的問題點。另外，我們在ClearQuest之Email Rules中，定制記錄使得當變更和缺陷被分配后，相關開發人員能夠及時收到Email通知。圖6為某一開發者當前的任務清單，可以看到，此開發人員有一界面變動和一個缺陷問題需要處理。 
圖6
5. 針對任務進行工作
開發人員針對被分配的活動進行工作，需要檢出(Check Out)和檢入(Check In)相關文件，檢出和檢入既可在Rose, Rose RealTime, Visual C++這些建模和編碼環境中進行，也可在ClearCase Explorer或Windows Explorer中完成。在檢出文件時，把對應的活動設為當前要處理的任務，這樣，UCM就會把以后檢入產生的文件新版本所作的任何改動和此活動相關聯起來，便于之后的活動交付和追溯比較。
圖7為某一開發者在Rose RealTime中，檢出一Capsule以修正某一缺陷。
圖7
6. 提交活動
開發人員完成活動后，把所做工作提交到項目共享工作區。提交時，可選擇提交哪些活動；對于目前還未完成的活動，或者暫時不用整合到項目中的活動，可選擇不提交。
圖8為某一開發者提交活動時的活動選擇畫面。
圖8
7. 整合項目
當開發人員把需要整合集成的活動提交到項目集成流后，項目整合人員首先鎖住集成流，然后在集成流上的某一視圖中進行程序的編譯，安裝的制作。
8. 建立新基線
如果此Build可以作為后續開發的基準，則由項目管理員創建新的基線，然后解鎖集成流，以允許后續的活動提交。新基線的創建可以針對實際有變更的UCM Component (vob)進行。
9. 從新基線Rebase
各開發人員從新的基線Rebase,更新其私有工作區，以包含此基線對應的目錄和文件之版本，反映項目的當前最新狀況。
10. 變更的追蹤
此UCM項目使用了ClearQuest集成，通過直觀的圖形界面，對于任何變更活動，都可以方便地查看具體的變動內容。
圖9為某一新增功能所涉及到的文件及其版本�？梢钥吹�，為了加入此功能，Rose模型的一個包(package)和若干C++源程序有變動，有的文件有一次以上的修改。
圖10顯示為了察看某一文件較之加入此功能前，有哪些具體修改所執行的操作。 
圖9 
五、幾點體會
采用UCM，使我們的配置管理工作變得簡單而有效，提高了項目開發的效率，提升了產品的品質。當然，在實際使用中，我們也遇到了一些問題，通過自己的研究或Rational的技術支持，這些問題大多在較短的時間內得到了解決。
近一年的UCM使用下來，我們有以下一些體會：VOB的規劃相當重要 建立UCM項目，首先要確定Component以及其下的目錄結構，不當的Component規劃會導致項目開發中不必要的新基線和rebase操作，也使得文檔，模型，源程序和測試數據分布紊亂且不易查找。創建UCM項目前，軟件的系統架構應已確定。根據軟件的子系統，模塊來建立相應的vob，使得屬于不同子系統，模塊的開發人員相互之間不會有干擾。 不同客戶版本的處理 有時，開發的軟件需要交付給不同的客戶，這些客戶對于產品有不同的需求。需要針對不同的客戶創建不同的UCM項目，它們共享部份或全部的Component。 ClearCase命令行操作不可避免 然UCM提供了簡便的圖形用戶界面，但對于ClearCase管理員，仍然需要用到基于ClearCase命令行的操作。因為UCM在提供簡單，易用性的同時，也隱藏了一些Base ClearCase的內容。諸如license的管理，vob的備份和恢復，被損壞的view之刪除，不同項目間的merge,等等，都需要項目的ClearCase管理員用ClearCase命令行來進行。 缺乏一定靈活性 UCM以活動和流的方式呈現給用戶。每個UCM項目有一個集成流和多個開發流，開發者從其開發流交付活動到集成流，并從集成流更新其開發流以包含其他開發者的工作，各開發流相互之間無法歸并。由ClearCase的分支被隱含，不少基于Base ClearCase的靈活功能無法使用。例如，有一 20人的開發團隊，開發者A要用到開發者B新的源程序，需要B先提交包含新的源程序的活動到集成流，然后由項目管理員建立新基線，再由A從新基線上更新其工作區以獲得開發者B新的源程序。而很可能此源程序還處在調試階段，卻被提交到了項目集成流。開發團隊越大，此類現象就越多。
六、結束語
以上是對Rational UCM的介紹和我們在項目中的實際應用情況�，F今為止，我們只在一個項目中采用了UCM，且不到一年，既使這樣，我們已深切感受到UCM給軟件開發帶來的效益。 UCM的2002版功能更強大，也更靈活，提供了一些在2001.A版中無法實現的功能，相信在以后的項目開發中，使用它或更新的版本，將更大程度上提高我們的軟件開發效率，提升我們的軟件品質。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
