CLM configuration management: Defining your component strategy

Nick Crossley, Persistent Systems
Last updated: 13 November 2017
Build basis: IBM Collaborative Lifecycle Management Solution (CLM) 6.0.4 and higher, IBM IoT Continuous Engineering (CE) Solution 6.0.4 and higher

This article is part of a series that provides guidance for planning configuration management for the IoT CE solution.

Introduction

Criteria for component boundaries

Reuse: If a group of artifacts is reused in different products, or in different ways or places in the same product or its variants, you can use different configurations of those artifacts to manage this reuse. That set of artifacts should be grouped into one component. Conversely, if two groups of artifacts need to be reused in different combinations at the same time, you want to put those two groups in different components.

• The collection of artifacts is intended for reuse in more than one context.
  Example: an engine control unit (ECU) that is used in both a truck and an SUV.
• The collection of artifacts is delivered to another party as a separate delivery.
  Example: a radio component delivered to a team working on the luxury model of a car and also to a third-party vendor of satellite technology.
• The collection of artifacts is delivered by a separate team or on a different cadence.
  Example: the stakeholder requirements need to be baselined before the system or functional requirements.
• The collection of artifacts has a separate delivery cycle.
  Example: a database consistency and repair tool might be shipped separately from the primary product that owns the database.
• The number of artifacts would be too large to manage in a single component.

• Consider using a single RM component for requirements that share the same set of type definitions.
  Although you can use component templates and import type definitions to manage shared types across a set of components, that approach increases the cost of maintenance, which you must weigh against the advantages of using separate components, as previously discussed.
  
  
• Use a single QM component for all the test plans that share any of the same test cases, test scripts, test environments, and so on, as well as those test artifacts themselves.
  You can separate the artifacts for one or more test plans but clone the shared artifacts to parallel versions in each component, however, this is not recommended. Such parallel versions become difficult to maintain, and you might need to migrate them to separate components in the future.
  
  
• In both RM and QM, you can only view artifacts from a single component at a time in a single view. You can use different views in different browser tabs or windows, but you might consider keeping artifacts in the same component if you always want to view those artifacts together in the application interface. Note that you can bring together information from multiple components in JRS and RPE reports, and in RELM views.

In current CLM releases, you can’t put configurations of two or more RM components that share any of the same artifacts into a single global configuration. This situation could easily happen when you reorganize your requirements into components. That is, if requirement #15 appears in component R1 (for some versions of requirement #15), and also exists in component R2 (for some different versions of requirement #15), you cannot add any configuration of component R1 to a global configuration that already contains a configuration of R2, and vice versa. This constraint might also apply to QM in future releases.

So, for a group of requirements that need to be used together in a single global configuration, you have two choices:

• Keep the requirements in one component.
• Split them into separate components but don’t continue cloning them between components in use.

How you group artifacts into components might be similar across applications if you follow a simple mapping from physical components. For example, if you group all the requirements for one circuit board in an A/V receiver into one RM component, you might group all the test cases for that circuit board into one QM component. However, this is not necessary; based on some of the preceding criteria, you might decide to group your test plans for the receiver by the type of test, or by the test team responsible for running the test.

Components vs. configurations

Global vs. local components

In a typical product composition structure, each global component is mirrored by at least one local component in each of the applications in use. For example, if you have a global component for the engine subsystem of a vehicle, that engine component probably also has requirements, test plans, firmware source code, and so on. Often, each application has more than one local component – for instance, the engine requirements might be subdivided into separate components for user requirements, system requirements, non-functional requirements, safety requirements, and so on. This approach allows you to develop configurations of those components on independent schedules, and to reuse baselines of those components appropriately.

This approach applies to each level of the configuration hierarchy, not just the leaves. So, while each ECU in an engine has its requirements, test plans, firmware source code, and so on, the engine as a whole is likely to have its own requirements, test plans, and so on. Configurations of these higher-level requirements and other items might appear directly as contributions to configurations of the global component, as shown in the example above, or they might appear indirectly through configurations of global components that group the requirements separately from the test plans. That is, with fine-grained component structures in RM and QM, you might have a global component whose configurations group together just a set of requirement components, and another global component whose configurations group together just test components.


or, with a software-oriented example:

Component organization

In themselves, components in GCM, RM, and QM are flat – they have no built-in structure or hierarchy. Instead, structure is built using configuration hierarchies in the GCM application, as shown in the earlier pictures.

Nonetheless, sometimes you want to organize your components into something other than a flat list. Organization is especially important if you have very large numbers of components.

You can organize global components by tagging them. Each tag is a string. A global component can have any number of tags. You can set up your own tagging conventions to define multiple independent organizations. For example, you might have one set of tags to classify components according to some government or industry part classification scheme, another set of tags to define the reuse capability of the components, and a third set of tags to indicate the ownership or origin of the components. With tags, you can find global components quickly and easily. From there, you can find configurations of those components.

CLM 6.0.4 introduced the ability to visualize your global component organization as a hierarchy using tags. The tagged view uses the forward slash character (/) to form a logical hierarchy of tag names. For example, the electronic/sensor/pressure tag might indicate a part classification scheme, and the us/ca/menlo tag might indicate a component designed or developed in your Menlo facility.

Because you can use multiple independent tags, consider using the first part of each tag string as an identifier of the classification scheme. The previous tags would be better as class/electronic/sensor/pressure and labgeo/us/ca/menlo.

Summary

Components make it easier to reuse and work with parts of a product or system. Component and stream strategy go hand-in-hand: you can’t finish one without the other. Read more about defining the configurations and stream patterns for the local and global components in the next article in this series: Patterns for stream usage.

Organize your artifacts into components to mirror your product building blocks, to reflect your product or team organizational structure, to maximize your opportunities for reuse, and to allow independent development by separate teams.

Avoid creating new components when creating simple variants of existing parts. Use configurations of the same component to differentiate variants.

Use tags to make it easy to find components and their configurations quickly, and to visualize component organization and structure in different ways.

For more information

Contact Tim Feeney at tfeeney@us.ibm.com or Kathryn Fryer at fryerk@ca.ibm.com.

See the following topics in IBM Knowledge Center:

• Activating configuration management in the RM and QM applications
• Using components in the RM and QM applications
• Creating components in the GCM application

About the author

Nick Crossley is a Senior Technical Staff Member at Persistent Systems, responsible for the architecture of product line engineering, version and variant management, configuration management, and cross-domain baselining in the CLM solution. Nick leads the OSLC standardization work on Configuration Management, and has over 40 years of experience with software tools and development. He can be contacted at nicholas_crossley@persistent.com.

© Copyright IBM Corporation 2017