Product Line Engineering

Strategies for Releases, Development, and Maintenance in Product Line Engineering: Part 2 Release and Maintenance

Posted in Article by danilo on December 20, 2011

This article is the final part on basic strategies for releases, development and maintenance. Of course the world is not as simple as I describe it in the article but you will be able to categorize your organization’s main approach based on the strategies. This part covers both internal collaboration (core asset development and use in products/variants) as well as external collaboration/deployment (product release and maintenance).

Release Strategies for Core Assets

While development strategies looked at the products/projects mapping, we will now look at the different strategies for releasing core assets to projects for use in product development.

clip_image003

One possible, and often taken, strategy is called Heartbeat Release. All the core assets of a product line are tested and released together in short, more or less regular intervals. This means maybe one release every two weeks, or up to six months, depending on the speed of change necessary in the respective domain. It’s a nice approach since all the assets released at one point in time are supposed to work together. That means there are less complex dependencies: you rely with your product on one specific heartbeat release of the core assets. The problem is: you have to wait for new features to be released in a heartbeat before you can actually use them officially in products. This takes some speed out of the game. Of course there are ways keep customers happy: If serious issues in a small set of products are found, create the fix for affected products in the release branch (or in an additional branch based on the release tag/label); test and ship the fixed products; and then move the fix into the next “public” release of the core assets. If this out of order fixing happens too often in between releases, you should shorten the heartbeat time and/or improve the quality assurance for core assets.

A speedier strategy is called Independent Release. Individual parts of the system, one core asset or maybe a group of related core assets, are released after a number of changes have been integrated and when the team responsible for this subset of assets thinks the assets are mature enough for release (i.e. use for creating products). While this obviously increases the speed of change, since it allows for partial updates of the product line assets, you have more complex dependencies. The groups of core assets can have each quite a number of independently released versions and might be used in different releases in different shipped products. This can happen especially if you are following a parallel development strategy and are doing frequent asynchronous product releases (see below). This might then lead to the extreme case of each product having a unique set of versions of the core assets. This can slow down issue fixing tremendously since a fix has to be applied to all the different versions and retested or the products have all have to upgrade to a new release of the affected assets (and also requires basically testing them all in worst case).

An even more radical strategy is the “Continuous Release”. In this strategy there is no release of core assets as such. There is one main development stream in which all the core assets are continuously updated with the newest developments. Each product development is normally based on the most current state of the core assets. Only during the maturing for release stage these products branch off from the main development stream into their private stream. This decouples them from further developments but permits finalization without too much disturbance from the progress. While this approach might sound impossible to manage to some of us, there are examples that this approach can work very successfully even for larger development organizations. For example, HP inkjet printers build from the Owen product line are developed in this way [Unfortunately you have to pay to read this article about it: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4339270].

Obviously this strategy works best when used in conjunction with a strong joint development approach and relatively short time spans for maturing the products for releases. It works best for products which do not require significant maintenance. Even though it creates fairly complex dependencies between products and core assets, it can be used for products which require maintenance. The effort to “rebase” released products must low enough and also the number of products in maintenance mode has to be low enough. Then you simply move the set of products with issues to the head of development stream and create a new release branch for them.

Release Strategies for Products

Similar to the release strategies for the core assets (which is an internal process) you will find different strategies for the release of the individual products made from a product line. Basically we can distinguish between synchronous and asynchronous release strategies.

clip_image004

In a “Synchronous Product Release” strategy you release (almost) all active products at the same time to the market. This is for instance the way many off-the-shelf software tools (like our own pure::variants) are shipped to the market. It simplifies dependencies and also can help to reduce test and qualification effort (especially for unit/component tests) since many tests do not have to be executed multiple times. If both test input and tested component are identical to previously test components in another product, there is no need to run test multiple times. However, it creates a peak in resource consumption for testing and qualification. This might be a too high peak for your organization, especially if lots of manual and/or long running tests per product are necessary.

An Asynchronous Product Release strategy permits releases of each product in their own time. This strategy is good if different customers or users require you to react in very different intervals. And it reduces for instance the testing load for your testing department before you release. On the other hand, synchronous release strategies often help to reduce the maintenance effort since all products are always based on the same release of core assets which cannot be guaranteed for asynchronous releases.

Please note that release in this context not necessarily means to actually ship the products to the customer. It also applies if the products are just made ready to be shipped. In many cases customer do not want to deploy new product releases too often since it creates logistic effort for them (e.g. when they have to update the flash memory of thousands or even millions of embedded devices).

Even when not all products get new releases automatically having releases ready for all products can be seen as a product maintenance strategy to make sure to have the latest fixes in all of your products and use this on demand as described in the next section on maintenance strategies.

Maintenance Strategies for Products

At last we will look what happens to a product after it has been released to the market. This is called maintenance or support phase. Here you have basically two choices again.

Choice one is called Event Triggered Maintenance: when a product is reported to be defective you update this product (and related products) and that’s it. That means only products which are effected by an issue are rebuilt, tested and released during maintenance. One additional choice here is between fixing the issue based on the old core assets release or migrating the old product to a newer, possibly the newest core assets release.

The other approach is Continuous Maintenance: Updates of older products to the new platform releases are done in the same way new products are released. That means basically there is no difference between previously released products or newly developed products: All are treated equally. This can significantly reduce the support effort since what you have released is at hand for all products all the time. That does not mean that you have to ship really all the products for which you have releases on the shelf. Most customers are not interested to get too frequent releases especially if they are not facing any issues. But in case the customer wants it you are prepared to ship a fixed product quickly.

Often a combination of the two approaches is the most sensible choices: Newer products are kept up-to-date by continuous maintenance. But after a certain time in the market older products are moved to event trigger maintenance until the final end of maintenance is reached.

Putting it together

If we taken the choices described above together, we can construct a nice feature model with two groups of three alternatives plus two groups with two alternatives.

image

That gives us 3x3x2x2 = 36 possible combinations to choose from. All of this does not give an exact answer to the question which approach to go with. In general select the most simple approach which allows to implement the business strategy for product development. Overall size of the development organization plays an important role. For smaller organizations a low number of teams have significant benefits in terms of coordination and communication. In larger organizations the decoupling of domain engineering and product projects can create a natural (and wanted) barrier to give the core asset development the necessary protection from individual project demands and allows for a better balance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: