提高部分
If the projects working to create the product variants are large both in
duration and staff size, the variants are likely to move farther and farther
from one another and from their common base. This makes it more difficult to craft modifications that can be delivered to multiple variants automatically.
如果項目是開發周期和人員規模都很大的差異性產品，這些差異性產品很容易在開發過程中偏差越來越大并且越來越偏離最初的共同的基準。這使得將修改自動交付到多個差異性工作流的操作更為困難。
A solution for scaling up is to use streams in an additional role: to manage
capabilities. You can control divergence between variants by building them out of more fundamental building blocks. Note that this is different from
conventional configuration management practices, which build systems from baselined configuration items; streams use baselines to group activities. The UCM approach provides the rigor of component centric baselines, but more eadily provides for development of variants.
針對這種更復雜應用的解決方案是使用工作流的新角色：管理功能。你可以通過從更底層的構件模塊中去構建這些差異性來控制它們的差別。注意這和傳統的配置管理實踐不同，傳統用法中基于已配置項來構建系統，工作流使用基線來組織活動。UCM的方法提供了嚴格的以組件為中心的基線，但更適于支持開發差異性開發。
In larger projects, streams can be useful on three levels:
1. Capturing microlevel changes. Once they are reviewed and tested, these changes can be baselined.6
2. Capturing macrolevel functionality (i.e., capabilities). The microlevel streams start from a baseline within these capability streams and are delivered back to them. Again, after QA, the capability would be baselined.
3. Building up product variants via deliveries from capability streams. After QA, baselines of these variants would be delivered to the customer.
在大型項目中，工作流在以下三個層次上起作用：
１． 捕獲微粒級的變更。一旦他們被復審和測試，這些變更可以被基線化。
２． 捕捉粗粒級的功能。（也就是功能）。微粒級工作流源自于這些功能工作流里的一個基線。在經過質量檢測后，這些功能可以再次被基線化。
３． 通過來自功能工作流的交付構建產品差異性。在經過質量檢測后，這些差異性的基線可以交付給用戶。
Example: GPS Tracking System with New Capability
舉例：帶有新功能的GPS跟蹤系統
Let's continue to follow the GPS Tracking System example, this time assuming that we need to add an entirely new capability (macrolevel change) requirement for the prestige car market: giving verbal directions to the user.
讓我們繼續GPS跟蹤系統的例子，這次我們假設我們需要增加一個全新的功能（粗粒級的變更）需求來滿足高檔車市場：給用戶提供文字提示。
The new capability is developed within the confines of a stream. This means that even though it was originally developed with only prestige cars in mind, it was developed in isolation; so it can be delivered to another stream -- say the stream used for the truck variant -- or another project.
Some questions arise when implementing such a macrolevel change:
這一新的功能在工作流的范圍內開發。這意味著即使它最初在高檔車工作流里開發，是在獨立的工作空間被開發的，所以它可以被交付到另一個工作流――即卡車差異性工作流---或者其他項目。當實施這些粗粒級的變更時會引發以下一些問題：
What if this shared software component depends on other components? How can we make sure that these are also included?
ClearCase does not need to read or understand the contents of the files it stores to understand dependencies between the files. Recall that activities record change sets; that is, an activity remembers the name and version of each file created as a result of that activity.
Therefore, when the development activities that were carried out within the (prestige car) stream are delivered to the truck project, we get not only the verbal directions component, but also the correct configuration of all other required files. This greatly simplifies reuse compared with the alternative: tracking the correct baseline of each and every required file or component.
如果這個共享軟件組件與其他組件有依賴關系怎么辦？我們如何可以保證其他組件也被包含進來？
ClearCase 不需要去讀懂或清楚它所存儲的文件的內容來弄明白它們之間的依賴關系�；叵胍幌禄顒邮怯涗涀兏�，也就是說，一個活動記得由它所生成的每個文件的名字和版本。
因此，當在（高檔車）工作流里開發的一個活動被交付到卡車項目時，我們不僅能得到文字提示組件，而且還得到其他所有必須文件的正確版本配置。和我們常用的另一個方法：追蹤每一個和所有必須文件或組件的正確基線相比，這將大大簡化了重用操作。
How do we know that the versions of these files are ready for use, and have been approved according to our quality procedures?
Activities do not just track modified files; they may also have associated workflow and data that will help ensure that quality procedures are met. For example, if the activity should be signed off before it is delivered to other streams, this can be enforced. This is where Rational ClearQuest comes in; basically, ClearQuest is a configurable workflow engine.
我們如何知道這些文件的版本已經可以使用？并且根據質量步驟通過審核？
活動不僅跟蹤修改的文件，它們也與工作流程和數據相關聯，這些信息有助于幫助確定質量步驟已符合要求。舉個例子，如果活動應該在交付到其他工作流之前被簽字確認，這個步驟可以在過程中強制實施。這就是為什么用到ClearQuest的原因。本質上，ClearQuest是一個可以定制的工作流引擎。
OK, but what if the truck project wanted to "tweak" this software component to fit their specific needs?
That would be a microlevel change. Again, the developers could create a stream to capture the changes in isolation so that they could be integrated with other changes for the truck project, and perhaps also delivered back to the prestige car project if the changes were useful to that team.
那好，但如果卡車項目想“揉捏”這個軟件組件以滿足它自身特定的需要呢？
這將會是一個微粒級的變更。再次說明，開發人員可以創建一個工作流去捕捉在他們各自工作流中的修改，以便他們可以和卡車項目的其他修改集成，而且如果這些變更對團隊成員有用，也可能會交付回給高擋車項目。
What if the verbal directions component(s) depended on other components already in use by the truck project?
We have four possibilities:
1. The truck project uses the same version of these components. No problem.
2. The truck project uses a more recent version of these components. The shared component (verbal directions) would have to be retested to ensure it is not broken by the more recent components it depends upon.
3. The truck project uses an older version of the components.
The components in use by the truck project would be updated (automatically) to match those required by the verbal directions component. Retesting the truck project might be required, because other parts of the truck system might be affected adversely by these new component versions.
4. The truck project uses a different version of the components
(i.e., it has also modified the components). This might result in automated file merges if the same files or directories were modified. If this happens, ClearCase will attempt to retain the modifications made by both projects. Human intervention is required and prompted for if conflicts occur, such as when
both projects change exactly the same line of a text file.
如果文字提示組件依賴于卡車項目中其他早已經在使用的組件呢？
我們有四種可能性：
１．卡車項目使用這些組件的相同版本。這沒有問題。
２．卡車項目使用這些組件的更新版本。共享組件（文字提示）將不得不被重新測試以保證它不會被它所倚賴的更新版本的組件所破壞。
３．卡車項目使用一個更老的版本。這些組件可以被更新（自動）來滿足那些文字提醒組件的需要，重新測試可呢能是必要的，因為卡車系統的其他部分可能會被這些新的組件版本所破壞。
4．卡車項目使用不同的版本。（也就是它也同時修改了這些組件）。這可能導致自動文件歸并如果是修改了相同的文件或目錄。如果是這樣，ClearCase會力圖保留兩個項目做的修改。這時候就需要人為干預并及時處理沖突，比如當兩個項目都修改了同一個一個文本文件的同一行時。
Reuse clearly remains a non-trivial task, but this scenario demonstrates that UCM streams make this goal achieveable by allowing teams to focus on capabilities, not individual files or components.
重用很顯然不是一個微不足道的問題，但這個場景表明UCM工作流通過允許團隊專注于功能，而不是單個文件或組件來使這個目標成為可能。
Quality Assurance
質量保證
All this talk of streams and automated deliveries from one stream to another is well and good, but it doesn't stop problems from creeping in through various sources, including:
A change that is delivered to integration before unit testing or other quality assurance procedures are completed.
A change that depends on other changes is delivered out of sequence and stalls integration.
A change that is delivered to the wrong stream; for example, the verbal directions capability might be delivered to the hand-held variant by mistake.
所有這些關于工作流和從一個工作流到另一個工作流自動交付的闡述都很好很實用，但它并不能避免在各種各樣資源中應用時產生的問題，比如：
一個變更未完成單元測試和其他質量保證過程就交付給集成
一個依賴于其他變更的變更被不按順序提交而阻礙了集成
一個變更被交付到錯誤的工作流；比如，文字提示功能可能被錯誤提交到手持設備差異性工作流。
Another challenge that arises in larger projects is simply tracking all the
changes that have been delivered and integrated. For example, how can we easily generate release notes detailing bugs fixed and added enhancements? UCM provides options to help out. For example, the deliver function can be scripted to enforce any given process, as in the following cases:
The project manager might need to move change requests into an "approved" state before the delivery can take place.
Change requests might have links to other dependent change requests; the deliver script could check that all dependencies have been delivered first.
另外一個在更大型項目中出現的挑戰是簡便追蹤所有被交付和集成的變更。舉例說，我們如何輕松生成發布說明，詳細列出所有修復的Bug和新增的優化功能？UCM提供了設置來幫你解決這個問題。比方說，交付功能可以通過程序來強制執行任何給定過程，如以下幾種情形：
在執行交付之前，項目經理可能需要知道處于“已批準”狀態的變更請求。
變更請求可以與其依賴的變更建立關聯，交付程序可以檢查所有被依賴的變更是否已經先被提交。
Because UCM is activity focused, it automatically provides a list of change
requests completed between baselines, so generation of release notes and
baseline auditing can be partially automated. This automation can then, in
turn, provide a project manager or release engineer with sufficient data to
decide whether a given baseline should be approved for release.
因為UCM是以活動為核心的，它自動提供在兩個基線之間的變更請求清單，所以發布說明的生成和基線審核可以部分自動化。這些自動化可以反過來提供項目經理或發布經理足夠的數據去決定是否批準給定基線的發布。
Streams for Phased Integration
用于階段集成的工作流
Some organizations use streams to implement phased integration, even if they are not developing variants. For example, a project might be divided into teams focusing on particular system areas, such as capabilities or logical subsystems. Individuals within a team deliver to a stream for "local" integration. When the team has integrated successfully, there is a second delivery to a system integration stream. This allows the project to employ different levels of formality: Small teams can have a lowceremony configuration management process, promoting collaboration wherever possible but employing more rigor where it matters -- at a system integration level.
一些組織使用工作流來實施階段集成，即使他們不是開發差異性產品。舉個例子，一個項目可能會被分解成關注特定系統領域的團隊，比如功能或邏輯子系統。團隊中的開發人員將活動交付到一個工作流做“本地”集成。當團隊成功集成后，再次交付到系統集成工作流進行集成。這允許項目采用不同層次的集成形式。小的團隊可能有一個低層次的配置管理過程，促進任何可能需要的協作，但在關鍵階段---系統集成一級應更嚴格。
Streams for Efficiency
用于提高開發效率的工作流
Using UCM streams to capture product capabilities is a logical and efficient
way to manage the complexities inherent in developing product variants in
both large- and small-scale projects. Using streams, the configuration manager can minimize project startup and integration time by automating delivery of a correct and consistent configuration of the versions of components that provide these product capabilities. This alleviates the need to manually track the dependencies of individual components and keeps the project running smoothly and efficiently.
無論是大型或小規模的項目，使用UCM工作流來捕捉產品功能是一個合理且有效的管理產品線差異性開發內在復雜性的途徑。使用工作流，配置管理員可以自動交付正確和一致的組件版本配置，這些組件組成了產品的功能，從而最大程度減少項目啟動和集成時間。這不近減輕了手工跟蹤單個組件依賴關系的工作量，同時使項目順暢而高效地進行。
References
參考文獻
Brian White and Geoffrey Clemm, Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction. Addison Wesley, 2000.
Notes
1 As implemented in Rational ClearCase v2002.
2 I've simplified definitions to fit the context of this article. The Glossary for Rational ClearCase provides more formal definitions.
3 RUP v2002 definition.
4 "Deliver" is an automated function in the ClearCase implementation of UCM.
5 The Deliver operation may also redeliver activities. An activity might be delivered more than once if work continues on the activity after the initial delivery. At a lower level, this means that extra file or directory versions have been created since the initial delivery.
6 This is true in UCM as implemented in ClearCase v2002. Previous versions of UCM were more restrictive with respect to where baselines could be applied.
注釋：
１． 如Rational ClearCase v2002中的實施。
２． 為適應本文上下文，我已簡化了術語的定義。Rational ClearCase的詞匯表有更正式的定義。
３． RUP V2002的定義。
４． “Deliver”是ClearCase UCM應用中的一個自動功能
５． Deliver操作可以再次交付活動。一個活動可以被交付不止一次，如果這個活動在第一次交付后仍一直被使用。更本質地講，這意味著有新的文件或目錄版本在第一次交付后被創建。
６． UCM在ClearCase V2002中的確是這樣應用的。以前版本的UCM在基線的應用上更為嚴格。
| UCM Definitions2 UCM定義2 l Activity: A unit of work performed by an individual. In UCM.an activity tracks a change set, that is, a list of versions of files created to perform the work. 活動：個人執行修改的組織單元。 在UCM中，一個活動追蹤一個變更集，即執行修改產生的文件版本列表。 Stream: A UCM construct that tracks activities. Work within a stream is always performed one activity at a time. Because streams track activities, and activities track file versions, at any given point in time a stream selects a single version of each file that corresponds to all work undertaken for the activities within that stream. 流：追蹤活動的UCM結構。 在流中工作時，往往一個時間點只執行一個活動。因為流追蹤活動，活動追蹤文件版本，所以在任何一個時間點，流選擇每個文件的一個版本，該版本和流中活動所進行的所有修改相對應。 Baseline: Data that identifies the versions of the components, files, and directories worked on. Baselines provide a consistent foundation for a team to work from, including the version of components,files, and directories that constitute a previous release. Baseline can be applied to streams to identify their configuration at a point in time 基線：標識進行工作的組件、文件、目錄的版本的數據�；�為團隊提供開始工作的一致基準版本，包括組成上一次發布的組件、文件、目錄的版本�；�可以用在流上，以識別某一時間點流的配置。 l Project: A UCM construct that groups configuration management information, such as which components will be worked on during the project. A project contains at least one stream. 項目：組織配置管理信息的一種UCM結構，比如哪些組件將項目中使用。一個項目至少包含一個流。 l View: A virtual working area showing artifacts (documents,code,directories, etc.). A view is associated with a stream, and the stream specifies the configuration of the view; that is, the stream selects the version of the artifacts the user will see. 視圖： 一個顯示工件（文件、代碼、目錄等）的虛擬工作空間。一個視圖與一個流關聯，流定義了視圖的配置，即，流選擇用戶將要看到的工件版本。 Component: A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a welldefined architecture3. In the context of configuration Management, a component groups a set of related directory and file elements. Typically, elements that make up a component are developed, integrated, and release together. 組件：一個系統中獨特的，幾乎獨立的，且可以替換的部分。它在一個定義準確的架構中實現一個獨立的功能。 在配置管理環境中，一個組件由一系列相關的目錄和文件元素組成，這些文件常 常被一起開發，集成和發布。 |
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
