提高部分
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. 组件：一个系统中独特的，几乎独立的，且可以替换的部分。它在一个定义准确的架构中实现一个独立的功能。 在配置管理环境中，一个组件由一系列相关的目录和文件元素组成，这些文件常 常被一起开发，集成和发布。 |
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
