Configuration Management in a Software Product LineJohn D. McGregorSchool of ComputingClemson UniversityClemson, SC [email protected] CohenSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, [email protected] product lines offer a comprehensivestrategy forsuccessfully building products. This strategy also greatlyexpands the number and types of artifacts upon which thatsuccess depends. Managing these artifacts over the life-time of the product line requires a carefully structured setof configurations and a rigorously enforced change man-agement process. In this paper we present an approach toconfiguration management in a software product line orga-nization that has evolved from our work with several prod-uct line organizations. The approach, which is added totraditional configuration management practices, managinginformation, including changes, about assets and productsensuring that they are exactly what they were intended tobe. We also briefly describe our technique for interactingwith groups to design effective configuration managementprocesses for software product lines.1 IntroductionA software product line organization manages a set ofproducts throughout development and some, if not all, oftheir useful life. The organization manages the assets usedto build those products and controls how those assets areallowed to change over time. Most development organi-zations have techniques for managing change within thecontext of developing a single product. A software prod-uct line organization extends this context to manage changewithin and among multiple projects both concurrently andover time. Further, the product line organization manages aweb of dependencies, which exist because assets are sharedamong multiple products and assets are used to build otherassets.The scale of change management in a software productline organization makes it cost effective to take a compre-hensive approach to the life cycles of assets and products.A comprehensive approach includes managing the supplychain of assets from their acquisition or creation to beingused by product teams to create products. The approachincludes coordinating, via the production plan, a variety ofsoftware supply chain activities such as developing an ac-quisition strategy, using externally available software, andmining existing assets to supply the component develop-ment and software system integration activities. It alsoincludes managing those non-code assets that are core toproduct line operation such as a scope document, a businesscase, and a concept of operations.Advances in configuration management (CM) and mate-rialization (MT) tools provide the asset support needed fora software product line. New configuration managementtools such as Subversion manage a wider range of informa-tion types than traditional source code control systems. Thisprovides tool support for managing a wide range of assettypes needed for product line production. Materializationsystems such as Buckminster [1] work with a collection ofCM repositories to provide a means of managing the com-plex relationships among requirements, code, test artifacts,documentation, and other artifacts. These systems provideasset management support to assemble components, prod-ucts, and other required assemblies such as plans and docu-mentation from the specified assets.The contribution of this paper is the specification of acomprehensive configuration management practice result-ing from a thorough analysis of product line operations andexperiences with actual product line organizations. Thepractice defines how change management policies and prac-tices apply to assets and products. The practice providesspecific techniques for implementing the policies and pro-cedures for version control, change management, and con-figuration management of the variety of assets characteristicof a software product line. We extend an existing meta-model, which decomposes the information needed to de-scribe assemblies of code assets, to apply to an entire prod-uct line core asset base. The meta-data are manipulatedrather than the asset itself eliminating referential problemsthat accompany strategic levels of reuse.Our goal was to investigate techniques for implementinga complete configuration management method to supportthe configuration management practice area of the SEI’sFramework for Product Line Practice. The data collectedabout configuration management practices come from re-peated application of general product line diagnostic in-struments and from direct engagements with customersconcerning the development of configuration managementpractices.To communicate clearly about our method, we definethe terms shown in Figure 1. The product line is a set ofsoftware-intensive systems sharing a common, managed setof features that satisfy specific needs of a particular mar-ket or mission, and that are developed from a common setof core assets in a prescribed way [?]. A product is somegrouping of functionality for which someone is willing topay. Products are built using assets including code but alsorequirements descriptions, a software architecture, produc-tion plan, tests, and software components. Assets are as-sembled from, or are collections of, artifacts. An artifact isan atomic piece that may be used in multiple assets. Prod-ucts, assets, and artifacts are referred to as configurationitems (CIs) with respect to the configuration managementsystem. A configuration description (CD) is a specificationfor a configuration item including perhaps a list of config-uration items that constitute the CI. A request links one ormore CDs and a means to realize the CDs. The request men-tions one or more locators, which specifies the locations ofrepositories. The name of a asset, given in the request, isused to determine which repository is used. We will use theterm repository to mean a collection of items that is con-trolled by a tool. For example, a configuration managementtool could manage a code repository. A text managementtool manage a repository for document chapters. We willexpand on these definitions later.Figure 1 also shows that a change request references spe-cific assets or products that are to be changed. This entityis the interface between the information about the manageditems and the administrative change process. We will focuson the managed items and tie it to the administrativeprocesswithout giving details of the administration.To illustrate