Software Product Lines (SPL)

This Chapter describes background information relevant to this research. It is organized as follows: Section2.1introduces concepts regarding Software Product Lines; Software Testing is introduced in Section2.2; Section2.3sketches the relationship between the previously addressed concepts; Chapter Summary is addressed in Section2.4.

2.1 Software Product Lines (SPL)

The software industry has continuously been challenged to improve its engineering practice aiming at delivering products in a faster and more reliable way, since the way that goods are produced has changed significantly in the course of time. Formerly goods were handcrafted for individual customers. Gradually, the number of people who could afford to buy various kinds of products increased (Pohl et al.,2005). Furthermore, it is important to point out that no two customers are identical. Each has unique requirements that can only be completely satisfied by a custom solution. However, software organizations must target large homogeneous markets in order to keep development costs within reason, essentially treating their customers as if they are identical.

This reason demonstrates the consequent competitiveness software development industry has experienced. It has increasingly become a concern for companies of all sizes and in all markets to develop strategies to meet the needs stated above.

A growing number of software development organizations are adopting strategies that emphasize proactive reuse, interchangeable components, and multi-product planning cycles to construct high-quality products faster and cheaper (McGregor et al.,2002), thereby meeting customer needs. The SPL engineering seamlessly address these strategies.

SPL engineering is emerging as a viable and important development paradigm allowing companies to realize improvements in time to market, cost, productivity, quality, and other business drivers (Denger and Kolb,2006;Pohl et al.,2005). Software product lines can also enable rapid market entry and flexible response, and provide a capability for mass customization (Northrop, 2002). By definition, a SPL is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (Clements and Northrop,2001).

In SPL, products are developed from a common set of assets, in contrast to being developed separately, from scratch, or in an arbitrary fashion (Clements and Northrop,2001). In addition, in constrast with what is customary, “design reuse” in SPL does not simply mean taking an

2.1. SOFTWARE PRODUCT LINES (SPL)

existing design, copying it and modifying it to some particular need, but rather the development of a model (or set of models) that can be reused in a disciplined fashion. SPL techniques explicitly consolidate and capitalize on commonality throughout the product line. They formally manage and control the variations among the products in the product line. New solutions are developed by assembling partial solutions and/or by configuring generic ones. Only the unique features of each solution, represented by product variations, must be specified because the common ones can be safely assumed. It eliminates duplication of effort in the engineering processes.

Yet, it has gained increasing attention by industry over recent years (Linden et al.,2007). It has proven successful in a variety of settings, including large and small organizations in business, industry, and governmental sectors, and across a variety of domains (Käkölä and Dueñas,2006), ranging from mobile phones to satellite ground station systems (Weiss,2008).

As real world motivation, organizations use product line practices to (Northrop and Clements, 2007): achieve large scale productivity gains, improve time to market, maintain market presence, sustain unprecedented growth, achieve greater market agility, compensate for an inability to hire, enable mass customization, get control of diverse product configurations, improve product quality, increase customer satisfaction, increase predictability of cost, schedule, and quality.

Ideas common to most successful product line efforts encompasses, besides exploring commonality among products to strategically reuse software artifacts, also the adoption of architecture -centric development and a two-tiered organizational structure (McGregor et al., 2002).

The SPL development begins by identifying the domain, deciding a set of products com-prising the product line and then proceeds by identifying what requirements are common to all products (commonality), and what differentiate them (variability). Commonality and variability concepts are key prerequisites for software product lines (Klaus Pohl and van der Linden,2005).

Architectureis also a key concept of software product line engineering. It determines how products are derived efficiently from the core assets. To allow the derivation of several different products, a product line architecture has to deal with variation. The architecture’s support for variation determines the scope of the product line (Rommes and America,2006), so that it can be configured to match a diverse range of requirements.

Moreover, SPL requires an organization to involve two types of development activities, one responsible for developing reusable assets (core asset development) and the other responsible for the development of products that use those assets (product development). These, taken together with management, are the essential activities underlying SPL.

2.1. SOFTWARE PRODUCT LINES (SPL)

2.1.1 SPL Essential Activities

As mentioned, software product lines engineering involves three essential activities, as shown in Figure2.1(Clements and Northrop,2001): core asset development, product development, and management. Each of these activities is essential, as is the blending of all three. The rotating arrows indicate not only that core assets are used to develop product but also that revisions of existing core assets or even new core assets might, and most often do, evolve out of product development. There is a strong feedback loop between the core assets and the products.

Moreover, strong management at multiple levels is needed throughout. Management oversees core asset and product development. Management orchestrates all activities and processes needed to make the three essential activities work together. Each activity is next detailed:

Figure 2.1 Essential Product Line Activities

Core asset development

Also known as domain engineering, it forms the basis for the software product line. The goal of this activity is to define the commonality and the variability of the product line, and thus for establishing the reusable artifacts and then a production capability for products (Pohl et al.,2005). It also involves the evolution of the assets in response to product feedback, new

2.1. SOFTWARE PRODUCT LINES (SPL)

market needs, and so on (Clements and Northrop,2001). Figure2.2illustrates the core asset development activity along with its outputs and influential contextual factors.

The activity of core asset development is iterative. The rotating arrows in Figure2.2suggest that there is no one-way causal relationship from inputs to outputs, they rather affect each other.

For example, expanding the product line scope (one of the outputs) may admit whole new classes of systems to examine as possible sources of legacy assets (part of the context). Correspondingly, a production constraint may lead to restrictions on the product line architecture (an output).

This restriction, in turn, will determine which preexisting assets (another contextual factor) are candidates for reuse or mining (Northrop,2002).

Core assets include, but are not limited to, the architecture and its documentation, specifica-tions, software components, tools such as component or application generators, performance models, schedules, budgets, test plans, test cases, work plans, and process descriptions (Clements and Northrop,2001). Although it may be possible to create core assets that can be used across the products without any adaptations, in many cases some adaptations are required to make core assets usable in the broader context of a product line. Variation mechanisms used in core assets help to control the required adaptations and to support the differences among the software products (Bachmann and Clements,2005). These adaptations should be planned before development and made easy for the product development team to use without putting at risk existing properties of the core assets.

Figure 2.2 Core Asset Development

2.1. SOFTWARE PRODUCT LINES (SPL)

Product development

Also known as application engineering, this activity creates individual products by reusing the core assets, gives feedback to core asset development, and evolves the products. Figure2.3 illustrates the product development activity along with its outputs and influential contextual factors.

Product development uses the core assets, in accordance with the production plan, to produce products that meet their respective requirements, as defined in the product line scope, all artifacts derived from core assets development, as previously shown in Figure2.2.

As in Figure 2.2, the rotating arrows in Figure 2.3 indicate iteration and involved rela-tionships. For example, the existence and availability of a particular product may well affect the requirements for a subsequent product. As another example, building a product that has previously unrecognized commonality with another product already in the product line will create pressure to update the core assets and provide a basis for exploiting that commonality for future products (Northrop,2002). Moreover, this activity has an obligation to give feedback on any problems or deficiencies encountered with the core assets, in order to keep the core asset base in accordance with the products.

Figure 2.3 Product Development

Management

It includes technical and organizational management, where technical management is responsible for requirement control and the coordination between core asset and product development. Not only technical aspects, here represented by the development of core assets and products, are