Configuration Management in Software Product Lines

Configuration Management in Software Product Lines Asim Rahman & Rashid Awan Department Of Systems and Software Engineering, School of Engineering, Blekinge Institute of Technology, SE-372 25 Ronneby, Sweden. {asra03/raaw03}@student.bth.se Abstract Software Configuration Management (SCM) is now recognized by the Software Engineering world as important aspect of software development especially for large and complex software systems. It has also become a vital part of the most widely used software process improvement frameworks. Software Product Line is a new phenomenon that has gained considerable attention during the last decade as an effective was of reuse within the organization. In this document, we present the overview of SCM activities necessary for software product line organization. [Keywords: Configuration Management, Software Product Lines (SPL)] 1. Introduction Software Configuration Management (SCM) is a disciplined approach used to manage the evolution of large and complex software systems through well defined process and control mechanisms [4] [5]. The importance of SCM has been recognized by many researcher and organizations [3] [6] [7]. The most widely used CM practices come from standards defined by Institute of Electrical and Electronics Engineers (IEEE) [6] The International Organization of Standardization (ISO) [3] and Software Engineering Institute (SEI ) [7]. This report analyzes the configuration management activities required for software product lines, a new reuse approach that has emerged in the last decade; the goal remains the same, decreas ing time and effort. The approach is particularly useful when making large and complex software. Section 1 gives an introduction into the Software Product Lines, brief overview of typical SCM activities and the research questions that the report attempts to answer. In section 2, the importance of CM activities in Product Lines is discussed. Section 3 presents dissimilarities between of CM practices in single products and the software product lines. Section 4 of the report discusses the core CM practices for product line organizations. Section 5 presents a case study of a Philips, an organization that has adopted the product line approach; their experiences with the CM practices are outlined. We present the conclusions of our study in the end. In order to proceed further we must first convey our understanding of a software product line. 1.1. Software Product Line (SPL) As the software sizes and complexity grow, more and more organizations realize that they cannot afford to develop multiple software products one at a time [1] [2] [9]. They are required to add new functionality to existing products as well as introduce newer products at a rapid pace to be able to compete in the market. Achieving component based software reuse assumes (or is intended for) a world-wide market divided into component producer, component consumer and the market place [9, p.1]. However, the shift from world-wide reuse of components to organization-wide reuse has proved this to be over ambitious [9, p.1]. This has given birth to a new philosophy of software reuse known as software product lines. The overall objective of a software product line is to reduce the overall engineering effort by first deriving and later managing the commonalities and variability of the similar systems [8]. The commonalties derived in the products are designed and implemented in such a way that all products can utilize those work products. To further clarify the idea of product line let consider the example of consumer electronics. Televisions (TVs), Video Recorders (VCRs), Set-Top Boxes (STBs), Compact Disks (CDs), Digital Versatile Disk (DVDs) are some of the products. As the technology in hardware improves, the software that runs the hardware becomes more and more complex. Companies in the business such as Philips have adopted the product line approach to cope with the diversity within a TV or VCR [10]. Moreover, the product line approach not only helps deliver products faster, it also facilitates in integrating combinations of these products (TV, VCR etc.) into variety of products by managing the commonalities and variabilities that exist amongst them [10]. 1.2. Overview of SCM activities

This section presents an overview of typical SCM activities in software development life cycle. The literature [4][5][6][7] groups SCM activities into four categories: configuration identification, configuration control, status accounting, and configuration audits and review. The configuration identification activities mainly identify the items that are to be controlled; these items are identified, named and their other physical characteristics recorded [6]. Moreover, procedure for defining baselines (and changes to it) for the Configuration Items (CI) are documented. In case of subcontracted software, special identification and labeling schemes may be needed. Configuration control activities define how changes to the CIs are requested, evaluated, approved or disapproved and implemented. It defines the sequence of steps that are to be followed to incorporate a change into a CI [5][6]. The configuration status accounting activities determine things such as what elements are to be tracked for changes to the CI and baselines, the type and frequency of reports, how the information is to be collected, stored, processed and reported etc[6][7]. The configuration audits and review activities (as the name itself suggest) are the audits and reviews to be carried out for the project; their objective, the CI and the persons involved, schedule and process, approval criteria etc are planned[6]. Activities that coordinate changes to interfacing item (hardware or support software) are also identified. In case of sub-contracted software (or third party software e.g. COTS), these activities include incorporation of subcontracted as well as acquired software (CIs) into the developed software. Other SCM activities include agreement and monitoring mechanism to check process compliance, audits and reviews of the subcontracted CIs, pro cedures to verify, validate and merge subcontracted software, security of information and traceability of ownership and the change process of the subcontracted CIs [7]. All the above mentioned activities are planned, scheduled and their sequence of occurrence defined with in the project. Moreover, resources are explicitly allocated to perform these activities. Resources include personnel, tools, techniques, equipment, training etc. 1.3. Research Questions In this report we try to analyze the purpose and benefits of configuration management activities in software product lines. Below we list our research question that we will attempt to answer: 1. Why CM is important in SPL? 2. Delta between CM activities in Product Development and Product Family development? 3. What activities should CM support in product lines? 2. Importance of CM in SPL The goals of configuration management are to eliminate confusion and errors due to different versions of artifacts. Plan it or plan to be overwhelmed by it [11]. Introducing a CM procedure into software development cycle would help in establishing and maintaining integrity of products throughout the whole lifecycle. Configuration management is particularly important during development of the products but also extremely important when handling maintenance of the software [11]. Figure 1 Configuration Management and Software Product Lines [1] In general, developing a product line involves core asset development and product development. Both require ascetic technical and organizational management [1]. These concepts are presented in pictorial form in figure1. Each rotating circle represents one of the essential activities. The three circles are linked together showing that they are linked, iterative and can occur in any order. The core asset and product development can occur in any order depending upon the approach the organization adopts (top down or bottom up). Either new products are built from core assets or core assets are extracted from existing products [1] [14]. The rotating arrows in the figure show that not only the core assets are used to develop products, but also new revisions of existing core assets and new core assets might evolve out of product development. However, more often than not, core asset and product development is coordinated effort [1] [14]. The figure above also shows the multidimensional role of CM in software product lines. As core asset in a software product line represents the most reusable artefacts that constitute a product line; therefore managing their configurations holds immense importance. From

these core assets various products are derived comprising of these core assets as well as some product specific assets. The management of these core assets must be coordinate under a single process [1]. One important aspect of the Product Line (as mentioned earlier) is managing variability. So what do we mean by variability that needs to be managed. Variability. Steffen Thiel and Andreas Hein [12] define variability as the difference between single products. Svahnberg [13] describes variability as the ability to change or customize the system. Variable software architecture implies that the changes in the architecture have been anticipated and facilitated with the introduction of variation points. These variation points in fact help in delaying certain design decision. A generic design decision is taken for the moment till a more specific one is made at a later stage. Variability can be introduced at various levels of abstraction [13]. The introduction of variation points in architecture implies that the architecture is evolution supportive (at least that is the aim). By evolution supportive we mean that the future changes in the architecture are anticipated and hence the evolution is gracefully [13]. Hence, proper management of variability required a unified process. Since a product line would normally consist of a number of products, having various versions that are in turn building upon different versions of components. Therefore, a CM process for product line strongly revolves around tools that make this possible. To further increase our understanding of what CM activities should be supported by product line, below we draw dissimilarities between the CM practices of product line in comparison with single systems. 3. Dissimilarities in CM practices: Single Systems vs. Product Lines CM for product lines is more complex than for the single systems. Below we present a brief comparison between the how single product development and product line differ in CM practices. Configuration of system vs. products: Configuration for single systems maintains versions of configuration items that constitute a particular version of the product [1]. On the other hand, a CM for product lines maintains such configuration for each version of every product. CM Process: In single product development, each version of the product may be managed separately. Since products within a product line are built upon shared (core) assets, the product line is usually managed through a unified CM process [1]. Control of Core Assets: Since core assets are written by one team but used by many, controlling the configuration of core assets is extremely important [1]. Tool Support: Only selective tools can be used for product line domain. A configuration management tool should support capture the commonality and variabilities of the products in the product line at different level firstly during the initial phases of the development of product line (scoping, feature pla nning, architectural design, assessment and transformation to component specification) to the actual product instantiation [2]. 4. Configuration Management Activities in Software Product Lines Configuration management process for software product lines should possess certain characteristics to fulfill the requirements of software product line as discussed above. In the following sections, each such capability is briefly described which software product lines CM should support. 4.1. Parallel development Different teams or persons work on the same items for different purposes. This fact requires two functionalities from the CM tool. First, there should not be any conflict between the teams while they are working on the same artifact. Second, the tool must support or facilitate the process of merging [14] [15]. So, the selected tool should have branch and join capabilities to support the above mentioned requirements. Several other branching/merging strategies are present in the literature for example [17]. Support of parallel development should be such that the same item of different products is available for different team members [18]. 4.2. Distributed engineering Organizations working on product line may be located on different development or maintenance site. In addition, those teams may be working on different development environment. Due to those reason, CM should not only support consistency of replication of configuration items but also should support heterogeneous development environments with import/export features [14] [15]. Support for distributed should be such that the integrity of the multiple libraries of the same configuration item is in control even when teams are not located on same place [18]. 4.3. Build and release management

Build and release manageme nt is important in software product line context. Build management is referred to creation of a version of product, for the purpose of integration or testing. Release management is referred to build final customer solution. For product lines, release management is often referred to release of core assets for product developers [14]. CM tool must support both build and release management when dealing with product lines. 4.4. Change Management During development, a change request may come from product development teams and core asset development teams. Company must define a defined change management mechanism to propose and analyze all the requested changes. An authorize group should also be assigned, often called Configuration Control Board (CCB) [15][16], to analyze and approve the proposed changes. The impact of changes in core assets on the whole product line should be analyzed. 4.5. Configuration and workspace management Individual information about each artifact should also be managed regardless the tool that are used supports it or not [14]. Configuration and workspace management information is all about what configuration is including testing and support environment and how users can create their own workspaces while using a configuration. 4.6. Configuration Status Accounting All essential and important information should be distributed to the involved staff through an efficient configuration status accounting system [17]. CSA solutions have to include World Wide Web publishing to offer reporting mechanisms to teams on multiple sites. To accomplish this, solution has to overcome the problem that may occur due to company s firewall [17]. 4.7. Configuration Audits Due to numerous numbers of artifacts from core assets and product development, regular and planned configuration audits and reviews should be organized to analyze configuration items. Perform configuration audits to maintain the integrity of the configuration baseline [18]. One thing which is more important in product line and distributed parallel development is to make sure whether all the CIs are present and available in the baselines [17]. A wrong baseline has an effect of a greater magnitude in PLs as more than one products will be affected. Absence of any single CI may lead to misleading results in the coming future which may affect related documents in both care asset and product development. 4.8. Process Management A defined and mature process of configuration management for the whole product life cycle in product lines development is essential. The processes about how to define configuration items and baselines including authorization policies for change management. This process should also be maintainable and must be continuously improved as product line development matures [14]. Typical processes are 4.8.1. Life Cycle Management Each configuration item is carefully handled and life cycle for each configuration item is defined. Changes in any item must be analyzed, authorized, planned, implemented, documented, reviewed, tracked and communicated. In addition, following information should also be included. list of possible actions (which will be occurred when dealing with an individual item) change authorization policies closure rules (defined when an item will close) 4.8.2. Role and Responsibilities Roles and responsibilities of each person participating in configuration management should be explicitly defined. Typical roles may be a list of persons who can issue a change, the person who will be responsible of auditing or taking backups etc. 4.8.3. Configuration Item Identification and Attributes A global nomenclature should be used to assign unique names. The names of same configuration item should be different for core assets components and product-specific components [14]. Attributes can also be assigned along with unique names due to various reasons. A typical example of an attribute may be has a proxy. CM system must support assigning these kinds of attributes. 4.8.4. Repository Management CM system should support the storage of configuration management with version management and branching. In addition, it should support an extensive of retrieving relevant information from that repository [14]. 5. Considerations while implementing CM activities for Software Product Lines Some important considerations should be kept in mind while introducing or using configuration management activities for software product lines [4]. All ongoing and opened change requests should be regularly checked along with their status. Change management process should be described in CM plan specially the information about when

changes are finished i.e. closed when dealing with distributed development. A generic CM plan should be prepared when relocated projects have their own CM plan. That generic CM plan can be referred for example at the time of release or merging components built on different locations. It is better to have a single central database for same kinds of change requests rather than to have separate databases and also project leaders should not have separate lists except database. 6. Practice Risks Several risks are involved if proper configuration management practices are not introduced right from the beginning of the product line development. Configuration management requires adequate control over unmanageable and numerous of a big number of artifacts, comes from core assets and product specific resources. Here are some practice risks which were mentioned by SEI [1]. 1.1. Process not sufficiently robust Due to the complexity of CM for product line as compared to single systems, while planning configuration management, extra considerations should be given and a robust CM process should be defined [1]. Without introduction a robust process, CM will fail and product line approach will become less efficient. 1.2. CM occurs too late CM practices should be introduced well before launching the first product from product lines otherwise building new versions of the product or rebuilding shipped versions will be very time consuming and expensive which is totally against the idea of software product lines [1]. 1.3. Multiple core asset evolution paths Core assets may evolve to different directions what was not planned before. It may happen due to two reasons, either due to enabling design of core asset for supporting different environments or by accident when core asset evolves within a specific product [1]. Both cases should not be avoided which may results in increasing the complexity of CM process. 1.4. Tool support not sufficiently robust Due to high importance and complexity of CM practices within product line, it would be relatively hard to handle this with out proper tool support. Even though several tool vendors declare that it is supported in their tool but a specific person should be assigned to evaluate those tools [1]. This evaluation requires good understanding of evaluator in both subjects i.e. product line and configuration management. 7. Case Study: Philips In this section, we present the configuration management approach used to realize a consumer electronics product population at Philips presented in [10]. Although a Product Population differs from a software product line, the CM process, tools and techniques used are the same. Product Population: Similar to a product line/family, a product population contains a set of products with many similarities. However, unlike product family, the products also have significant differences. 7.1. Architecture Philips has adopted a composition approach where they create products by plugging various combinations of components together. The product population is build upon reusable components based on the Koala Component Model. Each Koala component have required and provided interfaces through which it interacts with external environment. Products can be created by following steps: 1. Selecting a set of appropriate packages. Packages comprise of components and interface definitions 2. Instantiating the relevant components 3. Binding all type of interfaces 7.2. CM Aspects Philips addressed five issues in the configuration management domain. 7.2.1. Version Management of Files and Packages A conventional version management system is used to maintain the version history of the software assets (e.g. C headers and source files etc.) related with a package. The package team is responsible for formal releases for the package. Each version is assigned an identification number, consisting of a major number, a minor number and a patch letter e.g. 1.1b. The patch number identifies a bug fix where as the major and minor numbers indicate regular releases. Before releasing a package, all components are compiled, build and checked for errors. Only formal releases are available to the customers who maintain their own local configuration of the package. These packages are available to the customers through internet. Each release of the package is checked for backward compatibility. 7.2.2. Temporary Variation for Bug Fixes and feature enhancements

Philips recognized two kind of temporary variation: small and large. Small temporary variation, arises when one developer ties to fix a bug where as the other is adding feature to a component. In this scenario, they have developer specific branches in CM system which ensures that the changes one developer makes are not visible to other until the time of integration. Temporary variation at large arises before the release of package (product). As the package is utilized by many products, a branch in the package version is created before the release. All bug fixes are tagged to this release and no additional feature can be added here. Such kind of branches may live for a number of weeks but are finally closed when it becomes stable. All products are derived from the main branches of the packages. 7.2.3. Permanent Variation For permanent variation, Philips relies on the component technology. The reasons behind that are: first they are able to handle variation at architecture level rather than at CM level; second, it allows them to make later decision with the added advantage of flexibility; and third, it allows to exercise diversity outside the CM tool [10]. It is important to explain what they mean by diversity. Koala components contain diversity interfaces that contain a set of parameters that can be used to configure a component. The Koala component model believes in heavily parameterization of the interfaces in order to make the component more reusable. This parameter can be provided in forms of expressions that are later, evaluated and translated by the Koala compiler into compile time diversity (#ifdefs statements in C). 7.2.4. Build Support separated from CM Philips maintains a build environment separate from the CM system for three reasons. First, the organization cannot agree upon one standard CM tool to be used by all the teams. Secondly, they focus on buying the best solution for the problems each team may have. Resorting to their own build system that utilizes Koala compiler, various C compilers and a makefile, it allows each team to choose the solution that suits them the best. The third argument (although not very compelling) is that they would like to compile and link products in dependent of the CM system, at any place and at anytime. It allows them to play with the code anywhere. 7.2.5. Distributed Development Many commercial CM tools provide support to distribute the CM databases anywhere in the world. Philips are not with the idea for the following reasons: Firstly, this will ensure a standard CM tool to be used for the whole organization. Secondly, they want their software to remain independent of any CM tool. Lastly, they want to their packages to remain vendor independent and therefore adopt a small company s approach for the development of their packages. 8. Discussion In the Philips case study, we have observed that Philips does not follow some of the CM activities specific for the Product Line organization. In this section, we try to find out the possible reasons behind it. The main surprise is that Philips does not use any standardize tool for managing CM related activities; the reason being that they want to give the teams a certain amount of independence to choose the tool that best suits their needs. SEI on the other hand proposes that a company should have a standardized CM tool [1]. Philips product line use component based upon the Koala component model. Component configuration is controlled through the mechanism provided by the Koala component model. This means that a major functionality of a CM tool is not utilized. Moreover, Philips does not use the build environment of the CM tool a well. The reason behind this is the same; limitations of the component technology used. Hence, looking at the Philips case study we can conclude that although tool support should be imperative for CM process in PLs, conventional methods are preferred due to limitations of the underlying technology that the PL builds upon. We also infer from the case study that commercial tool support for PLs might not be available and organizations are left with no other choice than to use conventional CM techniques. 9. Conclusions Managing the configuration of the components that constitute a product line is extremely important. The aim is to eliminate confusion and errors that may arise due to different versions of artifacts. We presented a case study of Philips, an organization who has adopted the product line approach. We discussed various CM activities in practice. We found that they have developed their CM process independent of any CM tool. The main reason behind their decision was that different development teams had varying requirements, which are hard to find in one tool. Secondly, even if one tool supported all the activities, it would be infeasible for the organization to buy it and later use it, for economic as well as functional reasons. In the report, we concluded answers of research questions that were raised at the start of the report. Importance of CM in SPL is related to different factors. Two important aspects which increase the importance of CM in product lines were found. Firstly, product line comprises of care asset development and

product development. Secondly, the concept of variability and commonalities make things complex. There are major differences in the CM process between single product and product family development. When talking about CM for single product, it means we have to maintain versions of configuration items while in the case of product family, CM maintains configuration for each version of the product in the product family. CM process can be carried out differently for each version of product while a unified process is required for all versions when dealing with product family. In product line, core assets are written by different persons while used by others so configuration of core assets is extremely important. Selecting a tool when dealing with product family requires different consideration for example tool must support variability and commonalities in the case of product line. There are certain CM activities which must be carried out when dealing with software product lines. It is realized that most of the CM activities are to some extent similar to normal product development. But SCM activities require more attention when dealing with software product line due to the inclusion of core asset development, product development and COTS concepts. In addition, it may lead to unrecoverable situations if not carefully handled from the start. The CM Activities for a product line should facilitate parallel development, heterogeneous development environment, build and release management, an institutionalized change management process, along with reporting and audits to ensure better control. References [1] Paul Clements and Linda Northrop, Software Product Lines Practices and Patterns, Addison-Wesley, 2002. [2]Jan Bosch, Design and Use of Software Architectures, Addison-Wesley, 2002. [3] The TickIT Guide: TickIT Executive Overview, Issure 5.0, Jan. 2001. http://www.tickit.org/overview.pdf [4] Reidar Conradi and Bernhard Westfechtel, Version Models for Software Configuration Management, ACM Computing Surveys (CSUR), Vol. 30 Issue 2, June 1998. [5] Hong Mei, Lu Zhang, Fuqing Yang, A Software Configuration Management Model for Supporting Component-Based Software Development, ACM SIGSOFT Software Engineering Notes, Vol. 26, Issue 2, March 2001. http://www.sei.cmu.edu/legacy/scm/papers/cm_plans/cm Plans.MasterToC.html [8] C. W. Krueger, Software Product Line Reuse in Practice, Proceeding of the 3 rd IEEE Symposium of Application-Specific Systems and Software Engineering Technology (ASSET 00) [9] Jan Bosch, Software Product Lines: Organizational Alternatives, University of Groningen, 2000. [10] Rob van Ommering, Configuration Management in Component Based Product Populations, 2000. [11] Jelte Johnson, Presentation on CM and Risk Management, Idenet (pad008), 2003. [12] Steffen Thiel and Andreas Hein, Systematic Integration of Variability into Product Line Architecture Design, SPLC2. LNCS 2379, pp.130-153, 2002. [13] Mikael Svahnberg, Supporting Software Architecture Evolution-Architecture Selection and Variability, PhD. Thesis at Blekinge Institute of Technology 2003. [14] A framework for Software Product Line Practice version 4.2, http://www.sei.cmu.edu/plp/frame_report/config.man.htm, May 2004. [15] Experiences: Distributed Development and Software Configuration Management, Ulf Asklund, Boris Magnusson, and Annita Persson, 9 th International Symposiium, SCM-9 Toulouse, France, September 1999 Proceedings. [16] CMMI http://www.sei.cmu.edu/cmmi/ [17] A Branching/Merging Strategy for Parallel Software Development, Jim Buffenbarger and Kirk Gruell, 9 th International Symposiium, SCM-9 Toulouse, France, September 1999 Proceedings. [18] Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice, Lawrence G. Jones and Albert L. Soule, July 2002 Product Line Practice Initiative [6] IEEE standard board, IEEE Standard for Software Configuration Management Plans, 1990. [7] Nadine M. Bounds, Susan Dart, CM Plans: The Beginning to your CM Solution, 1995.