Software product lines (SPLs) undergo numerous changes to accommodate evolving needs of various market segments [1]. While some changes may apply to specific members, others permeate throughout the product line, often finding their way into the platform. In effectively managing evolution, product line development organizations are often faced with the following questions:
- Are there general patterns of changes that are common in product lines?
- If so, what change management practices can be used to effectively manage these patterns?
We investigate these questions through a case study in a product line development organization (see the sidebar on how we conducted our study), identify three interesting patterns of change management, and suggest effective practices for addressing them.
Change Management in Product Lines
The evolution of several variants along with the product platform poses several challenges in SPLs. Even sophisticated change management systems are inadequate for managing the complex, interdependent changes that are incorporated in different product variants [6]. Changes in customer requirements and errors detected in product variants may require changes to the platform itself. As all the members of the product line will be affected by changes incorporated in the platform, it is often allowed to evolve independently for different market segments such that only the product variants that are immediately affected by the change are tested and rebuilt. Thus, the platform is branched into a family of platforms. Left unchecked, this practice could potentially undermine the advantages of using a platform and lead to a fragmented product line.
Motivated by this problem, we offer recommendations to help understand and control the ramifications of changes in product lines. We present three commonly faced patterns of changes incorporated in product lines and change management practices that mitigate their adverse effects. Though several techniques have been used by the software engineering community to address these challenges, our recommendations are novel in that they are tailored to product line engineering. Techniques like feature modeling, proposed by the SPL community, only partly address the problem (see the sidebar on related research) [4]. The recommendations we present here encompass different operationalizations that are complementary to such feature-based techniques.
Patterns in Change Management
1. Interdependencies among changes in variants: As product variants evolve, changes incorporated in product variants become dependent on one another. We use a simplified example to understand the complexity of these dependencies. Consider a core product platform that is used across three product variants (see Figure 1). The three variants evolve into different versions due to specific changes—for example, version 1 of variant 1 is subject to two changes to derive version 2.1 Some examples of such changes observed at SCMCo are shown in Table 1.
In Table 1, C3 refers to a change in an algorithm. It depends on C1, as it was significantly changed when C1 was incorporated. A customer who uses variant 3 also requests C3, in Version 3. Now, before implementing C3, (specific parts of) C1 on which C3 is dependent should also be implemented. However, C1 conflicts with or constrains C4, which is also part of variant 3. This pattern (typically more complex than described here) is common in the product line at SCMCo. In summary, interdependencies among changes incorporated in different variants pose a problem in managing product line evolution.
2. Increasing the degree of evolving variance: Variation points in the platform are locations in the design that provide alternative ways of deriving product variants. Table 2 lists a few examples from SCMCo. The degree of variance refers to the number of variants that can be derived using the alternatives available at variation points. The degree of variance supported by a platform can be increased by increasing the number of alternatives supported at each variation point. Figure 2 shows that the number of alternatives provided by three variation points increases as the product line evolves. However, a major factor that affects the degree of variance is the impact of changes incorporated in these variation points.
When variation point 3 is changed to introduce an additional alternative (support for a new labeling system), it affects the introduction of a new alternative at variation point 1 (support for a new material handling equipment) because the speed at which labels are prepared depends on the level of automation of material handling. Several constraints such as this that result from changes to variation points are shown in Figure 2. Also, changes made to variation points affect changes made to the product variants down the line. For example, the introduction of the new alternative in variation point 1 affects the way the changes C1 and C4 are implemented in variants 1 and 3 respectively (in Figure 1). Increasing variance results in numerous constraints across variation points.
Interdependencies among changes incorporated in different variants pose a problem in managing product line evolution.
3. Reinvented variations: In SPLs, the alternatives incorporated in a variant may already exist in another variant. However, due to the boundaries between application engineers who work on different product variants, it is often difficult to leverage such existing implementations. For example, an alternative being implemented in V3 was already implemented in V1. Unfortunately, due to a fragmented application engineering process, the design team was not even aware of this solution, thus resulting in duplicated effort.
Recommendations for Change Management
1. Modularize changes and variation points: Variation points should be designed to be independent of each other as much as possible and changes made to specific product variants should be isolated from other changes. Industry best practices such as design patterns and refactoring can be used to achieve modularization. Project managers should develop design guidelines in the form of a checklist of such practices that may be followed when implementing new variation points or making changes. This will help developers follow consistent practices across the product line and reduce interdependencies. For instance, `protected variations’, an analysis pattern proposed by Larman [7] (adapted for use with product lines) is an effective way to operationalize part of this guideline and reduce undesirable impacts of a variation on other design elements. Also, as a product variant evolves, dependencies between current and past changes may impact changes in other product variants (as described in Figure 1). Since such cases are not addressed by `protecting’ variations, each change in each variant that may evolve across both time and space must be isolated as much as possible from other changes. We suggest that modular design, a commonly acknowledged best practice in software engineering, when focused on variation points, will be very beneficial in SPLs.
2. Track the scope and life of variations: Since it is usually not possible to completely modularize variation points, it is essential to track their impact on other parts of the product platform. Similarly, it will be useful to track the changes made to a product variant as it evolves. This can be achieved by establishing traceability across various components of the product line. Traceability (the ability to describe and follow the life of any artifact in a development process) has been widely used in complex system development as an effective aid for impact analysis. It is also well recognized that traceability practices should be tailored based on project characteristics [11]. Common traceability practices that involve linking requirements, design elements, and source code modules do not specifically recognize variation points and product variants—concepts that are specific to product lines. Therefore, project managers should develop a customized traceability practice that specifically establishes traces to variation points, changes incorporated in product variants and interdependencies among them. Reference traceability models [11] can be specialized to represent this information in the form of traceability matrices or networks. We suggest that variation points should be considered as central to traceability practice in SPLs to effectively aid in impact analysis [9].
3. Facilitate reuse based on knowledge sharing: Development and change management practices should provide easy access to knowledge about variation points in the product line. This will help various stakeholders involved in the process (domain engineers, application engineers, sales, marketing and so forth) easily understand and exploit the existing variations when new requirements for variations are identified. Specifically, access to rationale behind variation points and the alternatives supported at each variation point will help developers identify opportunities for reusing existing designs and implementations. Several models and tools for acquiring and reusing design rationale that have been successfully applied in complex software development [8] may be adapted for managing knowledge about variations (see Table 3).
Conclusion
If left uncontrolled, changes incorporated in product lines will become very expensive to manage. The change management practices recommended here are fundamental to effectively controlling the evolution of SPLs. In general, a scalable product line management strategy that increases variety while emphasizing effective change management practices is essential to prevent uncontrolled evolution of the product platform into families of platforms. Though the guidelines have been carefully developed based on data from a case study, similar studies in other domains will help generalize the findings. Future research on developing specific operationalizations that are unique to product line engineering is ongoing. The development of tools that are embedded in work practices is essential for successful operationalization of our recommendations.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment