Many organizations struggle with the complexity inherent in developing a product family. This complexity can be partially managed by maintaining a strong focus on system architecture and program management techniques.Concentrating on the configuration management discipline, this article explains how the Unified Change Management (UCM) concept of streams can help organizations support multiple product family projects by reducing start-up timeframes, tracking changes, managing dependencies between product variants, and propagating changes between product variants.
在開發一個產品線時，許多組織為其內在版本的復雜性所困。通過重視系統架構設計和項目管理技巧可以部分解決這個問題。本文側重于從配置管理的角度，解析統一變更管理（UCM）中工作流的概念如何通過減少啟動時間，跟蹤變更，管理變更在不同產品中的依賴關系，并在產品間傳遞這些變更，以支持多個產品線項目的開發。
In typical product line development, several variants of a product are under development simultaneously. This can happen for any -- or sometimes all -- of the following reasons:
1、Products with the same basic architecture are needed to provide
different end-user services/functionality.
2、The same product needs to be deployed on different target
platforms (hardware or software).
3、Older versions of the system need maintenance support.
4、Development timeframes for multiple versions overlap; for example, Version 2 might still be under development when development of Version 3 is slated to begin.
在典型的產品線開發中，一個產品的幾種差異性版本會被同時開發。這種現象往往出現在以下任一個---或所有條件都滿足時：
1、具有相同的基礎架構的產品需要為不同的終端用戶提供服務/功能
2、相同的產品需要在不同的目標平臺上部署（硬件或軟件）
3、老的系統版本需要進行維護
4、多個版本的開發時間跨度出現交叉重疊，比如，版本2仍在開發，但版本3已經 準備啟動。
The simultaneous development of multiple variants presents a significant
challenge to the configuration manager: There is a delicate balancing act
between the need to share desirable changes across all variants and the
need to keep firm control over the configuration of a given product.
In the modern software development environment, the scope, frequency,
and volume of change, coupled with continually increasing system size and
complexity, makes change tracking extremely difficult, even for a single
project. With variants, this task becomes even more difficult. One way to
tackle it is by adopting the advanced configuration management practices
detailed in Rational's Unified Change Management (UCM)1 approach.
Based on studies of software development projects in a range of highly
effective organizations, UCM was developed to help codify and automate
change and configuration management best practices. It is implemented
with the Rational? ClearCase? software configuration management tool.
By applying the UCM concept of streams, organizations can efficiently
develop variants, even in large-scale systems. Streams allow different
project teams to work on a common set of artifacts independently, sharing
changes only when it is desirable to do so.
同時開發多個差異性版本給配置經理提出了一個嚴峻的挑戰：在滿足不同差異版本間變更共享的同時，繼續保持對指定產品的嚴格配置控制，這需要一個巧妙的平衡。在現代的軟件開發環境中，變更的范圍、頻率和數量隨著系統規模和復雜性的增長而不斷增長，使即使只追蹤單個產品的變更都非常困難。再加上多個差異性版本的存在，變更追蹤就更為艱難。Rational統一變更管理（UCM）提供了解決這個難題方法，它詳細闡述了先進的配置管理實踐經驗。UCM是在對大量高效開發組織的項目研究的基礎上，為幫助編碼、自動變更和配置管理而開發出來的配置管理最佳實踐。它使用Rational ClearCase軟件配置管理工具實施。通過應用UCM工作流的概念，組織可以有效地處理差異性，對大規模的系統也游韌有余。工作流允許不同項目團隊獨立工作于同一套軟件工件，只在需要的時候共享變更。
Managing Change
管理變更
In a software development environment, we can classify changes according to two levels of granularity:
1、Microlevel, day-to-day changes that individual developers make to a
component or set of components (e.g., bug fixes or small
enhancement requests).
2、Macrolevel changes that add significant new product capabilities to
the system.
在軟件開發環境中，我們可以把變更分為以下兩類級別：
1、微粒級，每個開發人員每天都要對組件或一系列組件進行的變更（比如，Bug修復或小的變更請求）
2、粗粒級，新增的主要產品功能。
When planning development of a new product variant, it is convenient to think in terms of extending capabilities. We would specify a variant in terms of adding a new set of capabilities to the existing set of capabilities provided by a product framework. We may distinguish between the macrolevel and icrolevel in a number of ways, but it is perhaps easiest to categorize macrolevel changes as those that are visible from a project management or end-user viewpoint: key features, performance improvements, and so on.
當規劃新產品差異版本開發時，從擴展功能的角度去考慮更方便些。我們以新增一系列新功能到已有產品框架功能來界定一個產品的差異性。我們可以通過多種方式區分粗粒級和微粒級變更，但也許最容易區分粗粒級變更的方式是從一個項目管理者或最終用戶的角度去看整個系統的功能：關鍵功能，性能優化等。
That said, management of microlevel changes is still very important.
Customers hate nothing more than to see old defects find their way back
into a release. You also want to be efficient about ensuring that bug fixes
and small enhancements are propagated across all product variants. A common practice within more advanced software development environments is to create and maintain an architecture with a set of components that do not need modification from one product variant to another. This is usually realized by a layered architecture: Perhaps a "business" layer provides components that automate business logic common across each variant. Similarly, a "system" layer might provide a set of components that perform lower-level functionality (e.g., operating system interfaces, hardware interfaces, middleware interfaces, etc.) that is invariant from one project to another. Unfortunately, it is still possible -- and even likely -- that a component might need to be modified for some, or even every, variant in any of the layers. For instance, there might be
subtle modifications in the business logic between projects, or a requirement to support new computing hardware. In this situation, it is much better to automate (or at least partially automate) the propagation of required changes to the relevant variant, than to have to make these changes manually.
也就是說，管理微粒級的變更將更為重要。用戶最討厭的莫過于看到老的缺陷又出現在新的版本中。你也同樣希望可以確信Bug修復和小的變更請求可以在所有產品差異性中都得到修復。在更高級的軟件開發環境中,常用的實踐是創建和維護一個具有一系列組件的系統架構，這個架構中的組件不需要在每個產品差異版本中修改。這通常被公認為分層架構：“業務層”可能包含自動實現了不同產品間相同的業務邏輯的組件。類似的，“系統層”可能提供一系列執行底層功能的組件。（如操作系統接口，硬件接口，中間層接口等）這些底層功能在不同產品間沒有差異。但是，仍然有可能，并且極有可能—個組件需要在某一個，甚至所有層中進行修改，并且每一層中都不相同。舉個例子，不同產品間可能在業務層存在微小差別，或者需要支持新的計算機硬件。在這種條件下，自動化（或至少部分自動化）傳遞相關差異版本間必要變更比不得不手工修改要好得多。
So, in summary, the goals of change management for developing product variants are:
1、Specify variants in terms of adding new capabilities to an existing set of selected capabilities.
2、Manage change at the microlevel and macrolevel ("product capability").
3、Streamline the management of microlevel changes.
Let's explore how to use UCM (see definitions in the sidebar) by working
through some scenarios.
所以，總的來說，產品差異性變更管理的目的是：
1、根據是否新增功能界定是否是差異性
2、在微粒和粗粒兩個級別上進行管理
3、將微粒級的變更管理流線化（參見側欄內定義）
讓我們通過演練以下幾個場景看看如何使用UCM
Setup for Variant Development
搭建差異版本開發環境
Imagine that a development organization wants to port a system from a UNIX platform to MSWindows, while continuing to support their UNIX-based customers. This is an example of a variant.
假設一個開發組織想將一個系統從Unix平臺遷移到MS windows平臺，同時繼續支持使用Unix平臺的客戶。這是一個差異性例子。
Project setup for variant development is a major hurdle for many software organizations. The first issue is often that they do not understand the need for robust configuration management practices to support variants. The organization might maintain multiple repositories (one per variant), each with slight differences -- and no one really understands what these differences
are.
創建支持差異性版本開發的項目環境是眾多軟件開發組織的主要障礙。主要問題是他們常常不清楚這需要一個強大的配置管理實踐來支持這些差異性開發。軟件組織可能同時有多個存儲庫（為每個差異性分配一個庫），每個庫都有著細微的差別，但沒有人真正清楚這些差別在哪。
Under these circumstances, the only way to propagate changes across variants is through "Copy and Paste." Changes to copied data then need to be maintained in each repository. But no one knows which repositories already have the change
and which do not. Ensuring a high quality product release will require a large amount of tedious and time-consuming inspections and adjustments.
在這種情況下，唯一的辦法是通過“拷貝、粘貼”的方式傳遞變更。修改的數據需要逐一更新到每個存儲庫。但沒人清楚哪個庫已經做了更新，哪些沒有。因此，為保證高質量的產品發布，需要耗費大量的人力和時間進行仔細檢查和校對。
A second issue is that, to start development of a variant with an existing set of artifacts, the team leader and/or architect must define a starting point for the development team and in many instances they choose component versions, rather than versions of individual files. This complicates project setup: It is not sufficient to track only component versions, because each variant might
modify the same component. For example, specifying Version 5 of a file management component is meaningless if there is a Version 5 for the UNIX platform variant and a different Version 5 for the Windows platform variant
第二個問題是，在原有工件的基礎上開發新的差異性，團隊負責人和/或系統架構師必須為開發團隊定義一個起點。而在很多情況下，他們會選擇組件版本，而不是單個文件的版本。這將使得環境的搭建更復雜：只跟蹤組件版本是不夠的，因為每個差異性版本都可能修改同一個組件。比如，只指定一個文件管理組件的版本5是沒有意義的，如果同時有一個 Unix平臺差異的版本5和另一個不同的Windows平臺差異的版本5。
Before starting work, development teams need to consider the following:
1、What is the quality of the initial component versions? Preferably, only well-tested and approved changes should be included in the foundation for the new project, so that the project team can avoid spending time on resolving broken builds. So, the team needs a way to quickly select just those component versions that have undergone appropriate levels of quality assurance.
2、What are the relationships between component versions? A component often has dependency relationships with several other components, so an incorrect set of component versions could cause integration problems. This means that a configuration management approach that focuses exclusively on components while neglecting their relationships is sub- optimal.
在開始工作前，開發團隊需要考慮以下方面因素：
初始組件版本的質量如何？最好是只把經過完全測試并通過批準的變更包含到新項目的基礎版本中，以免項目成員浪費時間去解決構建失敗的問題。因此，開發團隊需要有一種方式可以很快地選擇到那些已經達到質量保證的正確級別的組件版本。
組件版本間是什么關系？一個組件常常和其他幾個組件有關聯，因此一組不正確的組件版本將會導致集成問題。也就是說，一個只關注組件而忽略它們之間關系的配置管理方法并不是最佳的。
Large projects can spend an enormous amount of time determining the answers to these questions, so what is needed is a streamlined approach. Using UCM streams represents a very efficient approach. Each stream specifies the right version of every file. This greatly reduces the need to track file or component versions, and the dependencies between these versions, because the stream represents the foundation for a project in terms of a single entity.
規模大的項目將要花大量的時間去尋找這些問題的答案，所以我們需要的是一個流線化的方法。使用UCM工作流是一種非常有效的方式。每個工作流配置各個文件的正確版本。這大大減少了追蹤文件或模塊版本，以及這些版本之間的依賴關系的時間，因為工作流以單個實體的方式組成了項目的基礎。
Of course, a developer might not want the latest changes made in the stream if they have not have been tested. UCM streams have a baseline to record their configuration at a point in time, so the team lead can select not only a stream, but also a baseline within that stream, to provide a stable foundation for team members to work from. The stream concept represents a change in mindset for many experienced software configuration managers, most of whom are used to thinking of baselines as versions of components. But UCM extends the concept to improve efficiency: It defines a baseline for a stream, which in turn defines baselines for the components in that stream.
當然，如果工作流上的最新版本還未經過測試，開發人員可能不想要這樣的版本。 UCM工作流用基線來記錄在某個時間點的配置，因此團隊負責人不僅僅可以選擇工作流，還可以選擇工作流上的基線來給項目成員提供一個穩定的版本，做為開發的起點。工作流的概念體現了大多數經驗豐富的軟件配置管理員認識上的一個改變，他們中的許多人習慣把基線當作是組件的版本。但UCM擴展了這個概念并提高了效率：它定義了工作流的基線，這個基線反過來定義了這個工作流上組件的基線。
With this stream-based approach,larger projects can use UCM components -- rather than a myriad of small logical components – to represent large subsystems.
通過這種基于工作流的方法，更大的項目可以使用UCM組件—而不是無數的小邏輯組件---來組成大的子系統。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
