Towards an Agile Process for Building Software Product Lines

Software product lines are sets of software systems that share common features. Product lines are built as if they were a family of products, identifying those features that change and those that can be reused. There is an evident incompatibility between the requirements of software product lines and agile practices. We report on experiments that used Feature-Driven Development to build software product lines, and describe the minor extensions that were useful for developing software product lines. Software product lines (SPL) [4] are collections of software systems that share a common set of features. SPLs are an emerging software paradigm allowing for largescale reuse for companies, since software is built as if it were a family of products rather than an individual product. A family is a set of products that have common aspects and predicted variability [4]. Once an SPL has been developed, the process of software development is one of tailoring and configuring a product line, rather than building a product wholesale. Examples of products that have been considered as SPLs include engine controllers, type managers, and anti-lock braking systems. Noteworthy amongst many of these systems is their embedded nature. SPL development is usually a time-consuming and extremely expensive process. Key challenges include identifying features and variation points, capturing the product line architecture, and managing the configuration process. Approaches used for developing SPLs are typically architecture-based, particularly those for safety critical systems such as aero-engine controllers [5]. Models are considered helpful to assist in the feature identification process and in highlighting configurations. Agile development methods, such as Feature-Driven Development (FDD) [3], have evolved to meet a need for increased productivity, while dealing with challenges such as changing requirements. SPL methods have evolved to increase productivity, ideally via increased reuse. However, there is an apparent incompatibility between agile practices, and what is needed to develop SPLs. In particular, • The agile principle of emphasising simplicity, and implementing functionality that satisfies the current instead of future requirements, goes against the requirement to support different variation points and configurations in SPLs. • The agile principle of delivering working software frequently contrasts with the substantial up-front development time for an SPL in order to provide infrastructure, which can thereafter be configured and deployed. Towards an Agile Process for Building Software Product Lines 199 Despite these apparent incompatibilities, we believe that the SPL development process can benefit from agile development techniques. To evaluate this, we have carried out several experiments in using an agile process to build a SPL [1]. Our approach was to first assess existing agile processes to determine which might provide suitable practices for identifying SPL features, configurations, and variation points. We selected FDD because of its lightweight modelling capabilities, and because it provided substantial guidance on identifying system features, something that must also be done in SPL development. We then applied FDD directly to building a microwave oven software product line. Variants of a microwave considered included one with only a simple cooking facility, one with a weight sensor to gauge temperature and cooking time, and one with built-in recipes. We encountered two difficulties in applying FDD to building SPLs: integrating SPL architecture design into FDD; and incorporating component development in FDD. An architectural description is important for SPL development since it is a part of the SPL core assets and is reused by product development. Architecture and component development were integrated into FDD with minor extensions to the overall process; architecture is considered incrementally, following [6], and SPL variations are generated as a result of the agile refactoring practice. As a result of this case study, we constructed an extension to FDD. Two new phases were added: one for consideration of architecture (based on the Architectural Tradeoff Method [2]) and one for SPL component design. An argument as to why this remains an agile process is laid out in detail in [1], but a key point of note is that the architectural and component models that are produced are the simplest and smallest that help in identifying variation points in SPL development. We then applied the revised process to a further case study an e-commerce system in order to validate and further explore the approach. Our observations are that an agile process like FDD, which explicitly considers features as first-class artifacts in system development, is well-suited to SPL development, as long as additional consideration of SPL architecture and SPL component design is added to the approach. Full details of the case studies can be found in [1].