Product Line Engineering

Strategies for Releases, Development, and Maintenance in Product Line Engineering: Part 1 Product Development Organization

Posted in Article by danilo on September 3, 2011

When it comes to software product line development you have quite a number of choices how you can do things. For instance, depending on the domain for which a product line is developed, you can select between different product release, development and maintenance strategies. Knowing the choices and carefully selecting the most suitable one helps you to make your product line engineering development a success. The following article will briefly introduce some basic strategies to choose from and discusses some use cases.

Due to the length of the individual sections in the original article I split this into several posts. The first post will deal with organizational aspects of product development in product lines.

Development Strategies for Products

The development strategies I want to discuss are: Joint Development, Parallel Development and One by One Development.

spl_strategy_development_thumb2

In a joint development strategy products and reusable (core) assets as well as product specific assets are developed in a joint effort. The organization acts as one big virtual team with main focus on the product line as a whole. To implement that strategy you often have either a relatively small team of generalists doing almost everything or for larger systems often several specialist teams for different parts of the system.

These specialist teams or the individual generalists cooperate in order to provide at some point in time releases of some or of all products currently under development (see release strategies for core assets and products below). Since the teams and their members are basically doomed to communicate properly and coordinate themselves it can be very efficient.

This usually true up to a certain point of complexity of the product business. When the number of products to be developed in parallel gets very large or the non-reusable part per product is too large, this often demands a split into a team dealing with the foundation (reusable assets for all) and teams dealing with specific products/product groups.

Nevertheless, since this strategy puts a strong emphasis on the product line as a whole, it is in many cases very efficient for product lines with a high reuse degree across several products. Coordination effort especially for changes to existing functionality is often relatively low, since many change requests are related to a single team’s or developer’s area of responsibility and conflicts and dependencies can be easily discussed and handled. Essentially this in most cases the optimal strategy for product line development. Changing the organization of your development to support this strategy is often not an easy task, though. Project managers often see a lost: they do not have exclusive access to resources (== power) easily in this scenario.

In the next scenario, which I call parallel development strategy, you have several project teams developing one or more products or asset groups independently from other projects developing other products/assets. Usually the projects have their own timeline for releasing products and their own customers for these products. Main focus for each parallel team is the release of their individual products, not the product line as a whole.

While this is often combined with joint development for (some) core assets, in the most extreme case there is no joint development at all. Even reusable assets are developed in the individual product teams. This of course creates a huge demand for communication, coordination and also proper management of conflicts of interest in terms of implementation and prioritization of new reusable functionality and changes to existing assets.

“Traditional” product line approaches often seem to advocate the mixture of the joint development (for reusable assets) and parallel development (for products/variants) build on top of product line assets. This creates a clear separation between domain engineering and application engineering. But often limits the communication between those two sides since just as in parallel development it is either them or us for all teams. This limited communication has good and bad sides. Good is that there is some initial threshold before the product teams ask for reusable assets to be implemented. This limits the communication frequency and amount. However, sometimes the core asset development produces reusable assets upfront without use cases in the projects or in a way that they are not usable for the projects since requirements are not communicated properly by project teams. Or there is not enough knowledge related to the specific use case in the core asset team.

However, since but its nature, development inside the product projects is closer to those who give the money (== customers) it is the most often implemented strategy.

And finally you could take a very simple approach, which is the “One by One” approach. In this case you develop one product, and once you have finished development you move on to the next product. Basically you never develop more than one product at a time. Of course the last scenario is most unlikely in many cases but it is obviously the most simple one. In those cases where it is applicable, it can be extremely efficient, since there is a clear focus on a single target at a given time.

However, this does not mean that older products can be forgotten entirely: Usually someone in the organization has to provide support and maintenance for them. If the one-by-one approach is implemented by clone-and-own (you use a copy an existing product as starting point for the next product development) this will most likely lead to problems in case of defects found in older products: A fix to an issue introduced in one of the previous products which are the ancestors of a product has to be done several times, basically for each product descending from the product which introduced the issue. See product maintenance strategies in the follow-up article for a comprehensive discussion of this problem.

Stay tuned, next article will be dealing with release strategies.

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: