The current trend of globalization is pressuring industries to explore ways to diversify and deliver their products in a timely and efficient manner. Over the last decade, the software product line (SPL) has emerged as one of the most promising software development paradigms for drastically increasing the productivity of IT-related industries, enabling them to handle the diversity of the global market and reduce the amount of time to market.
A key idea in product line engineering is that most software systems are not new. Rather, software systems in an application domain share more commonalities than uniqueness, and most organizations build software systems in a particular domain, repeatedly releasing product variants by adding new features. This insight can be leveraged to improve the software development process. A systematic approach, known as product line engineering, has been developed to build product variants using product line assets including common architectures and components. These architectures and components are built with variation points based on the commonalities and variabilities of the products in the application domain.
History
The idea of reuse-based software development is often traced to McIlroy’s 1969 article [9], which proposed the idea of "mass produced software components" as the basis for application development. Later, Parnas developed the information hiding principle and the idea of program families, which became the engineering foundation for reusable component development and reuse-based application development. Neighbors introduced the concepts of domain and domain analysis [10], and provided the first systematic approach to domain engineering, known as Draco. Soon after, major research endeavors on software reuse and domain engineering followed [1, 46]. Carnegie Mellon University’s Software Engineering Institute (SEI) refined the concept of domain engineering further and developed a framework for reuse-based development of a family of closely related applications and called it product line engineering [2]. The framework includes management aspects as well as technical aspects of asset and product development.
A case of industrial practice of product line engineering was reported as far back as 1977. It was known as the Toshiba Software Factory, where a product line approach was applied to the development of a family of power generators [8]. This may be the first industrial case reported in the literature. Now, owing to government or European community sponsored large-scale research projects on software reuse, including the ARES, PRAISE, ESAPS, CAFÉ, and FAMILIES projects (see www.esi.es/en/Projects/Cafe/cafe.html), many cases of product line engineering in various industries have been reported (see www.sei.cmu.edu/ productlines/plp_hof.html).
Active areas of product line software engineering research include asset libraries, methods and tools, software architectures, componentry, generators and generative programming, product configuration methods, measurement and experimentation, and business and organizational issues. Application development framework technologies such as .NET, Enterprise JavaBeans, and service-oriented architecture are also areas of active research. Application of, or integration with other technology areas such as aspect-oriented software development and agent technologies are also being explored.
While advanced techniques are central to successful adoption of product line engineering, technical issues have deep and complex interactions with other non-technical areas including business and organizational issues. These areas are highlighted here.
Process, Organizational, and Technical Issues
The ultimate goal of product line engineering is to improve the productivity of product development and the quality of products and services a company provides. Increasing the level of reuse may not necessarily reduce the overall development cost due to asset development and management costs. When and how reusable assets are developed and used in product development will affect the effectiveness of product line-based product development. To maximize reuse profits, process, organizational, and technical aspects must be considered.
Process Aspect. Implementing a reuse program in a corporate environment requires a decision concerning when and where capital investment is to be made. There are three process models that are often used in adopting a reuse program: proactive, reactive, and extractive models [3, 7].
With the proactive model, an organization makes an upfront investment to develop reusable assets for the product line and products are developed using the assets. Although this approach can be effective for product lines in a mature and stable domain where product features can be predicted, it requires a large upfront investment.
In the reactive model, reusable assets are developed as needed when reuse opportunities arise. This approach may work well in a domain where product features cannot be predicted in advance. Although this approach does not require a large upfront investment, the cost for reengineering and retrofitting existing products with reusable assets can be high without a well thought-out common architectural basis.
Another approach proposed by Krueger [7], called the extractive model, stays between the proactive and reactive approaches. The extractive approach reuses one or more existing software products for the product line’s initial baseline. This approach can be effective for an organization that has accumulated development experiences and artifacts in a domain but wants to quickly transition from conventional to SPL engineering.
Organizational Aspect. There are two types of organizational approaches to establishing a reuse program that are commonly used in corporate environments: centralized and distributed asset development [3].
The centralized approach typically has an organizational unit dedicated to developing, distributing, and maintaining reusable assets. It also trains employees for product development projects. The organization has the product line-wide product and engineering vision and core expertise that can be shared among the projects. As this approach often requires pulling experts away from product development projects, it can only be successful where there is a strong commitment from the upper management.
With the distributed approach, a reuse program is implemented collaboratively by projects in the same product line and asset development and support responsibilities are distributed among projects. Although there is less overhead as asset development costs are distributed among projects, it may be difficult to coordinate asset development responsibilities if there is no common vision for the reuse program. Also, there must be a convincing cost-benefit model to solicit active participation. There is potential danger in the possibility that some projects may be willing to use others’ contributions while being reluctant to make their own investment for others.
Technical Aspect. Even though there are many issues from a technical perspective, they could be grouped into three basic areas: core asset development, product development, and runtime dynamism.
For core asset development, scoping and analyzing the domain of the product family is essential. Feature-oriented domain analysis is an approach used for this task. Identification and definition of common features and variation points are the main focus. Managing differences among products of a product line—variability management—is an important aspect.
In product development, product derivation from core assets, especially product line architecture, is an important activity. It includes selecting appropriate parts, extending the architecture, and resolving conflicts between functionalities as well as quality attributes. New requirements from customers, changes in technology, and future needs pose considerable challenges. Evolution in a product line is complex and needs more attention compared to traditional software development since most assets are utilized by products within the product line. Testing, traceability, and quality issues must be handled carefully.
Due to dynamic changes in the execution environment or various user requests that are not anticipated during development time, software must adapt its own behavior or compose different assets during runtime. Thus, the design of a SPL should be able to accommodate dynamic changes by utilizing predefined runtime binding information or self-managing capability. There have been only limited advances on this front, but it will be a key research area in the near future. Aspect-oriented development can be used as one of the enabling techniques for runtime dynamism in a product line.
Overview of the Section
This special section features articles that present the state of the art in SPL research and address a broad range of topics related to technical and managerial aspects of adopting product line initiatives within an organization. We have strived to strike a balance between academic and practitioner perspectives and present articles written by some of the world’s leading SPL researchers. The articles cover the adoption and diffusion of SPL, new methodologies and challenges, feature modeling and customization, product and change management, verification and testing, and cost estimation.
The article by Clements et al. provides a roadmap for SPL adoption. The authors discuss the Adoption Factory pattern, which focuses on products, processes, and the organization. It maps out the combination of technical and business activities that must occur. Specifically, the authors lay out the steps an organization new to SPL should take in order to adopt this approach for software development.
The next two articles discuss new methods in SPL practice and the challenges in managing the scope of software product families. Krueger compares three new methods for practicing SPL and argues that these methods offer tactical benefits over the first-generation SPL methods. Bosch presents two alternative approaches for overcoming the challenges in extending the scope of software product families and concludes that these methods are better suited for broad-scoped product families.
The subsequent four articles deal with feature modeling, variability management, and customization. Batory et al. explicate the challenges in analyzing feature models, particularly in an automated fashion using various tools and provide a research agenda. Eriksson et al. describe an approach called PLUSS, which integrates use case modeling and feature modeling to create a complete use case model for a family of systems. Lee and Muthig present an approach for feature-oriented variability management and identify the challenges based on their experiences in applying the PuLSE method to a number of industry cases. Czarnecki et al. introduce the concept of multi-level modeling for domain-specific platforms and provide mechanisms for mapping features to analysis models.
Two articles examine SPL product management and change management issues. Helferich et al. highlight the problems and pitfalls in product management and argue that for a product line to be successful, establishing tight integration and communication between marketing and technical personal is essential. Mohan and Ramesh discuss SPL change management patterns and suggest modularizing the changes and variation points, tracking the scope and life of variations, and facilitating reuse based on knowledge sharing.
The next two articles are concerned with verification and testing. Kishi and Noda propose a systematic method to verify designs within a product line based on formal verification techniques. Pohl and Metzger discuss the challenges faced in SPL testing and outline six essential principles for SPL system testing based on their experiences with a number of European projects.
Peña et al. explore the intersection of agent-oriented software engineering and product line engineering. In particular, the authors discuss the feasibility and benefits of multi-agent systems product lines and the associated challenges.
The last article presents a cost estimation model for the product line life cycle. In et al. have developed a model called qCOPLIMO, which takes into account the relative cost of writing for reuse for initial product line development, and relative cost for reuse for the subsequent product development cases.
Future Research Directions
Product lines with thousands of features have been reported recently and complexity management has become a fundamental issue in such product lines. When a family of products is derived from a common asset base and when these products and assets evolve over time, the complexity of managing products and assets increases an order of magnitude compared to managing versions of a single product. Management of a large number of features and complex dependencies between them, asset variants and variation points associated with these features, and product configurations require considerable further research.
It has been argued that systems configured from components that have been tested and used previously should be more reliable. However, when asset components are integrated, unexpected behaviors that cannot be predicted from the behavior of the components used can emerge, which may result in disastrous consequences. This is generally known as feature interaction problem. Techniques for uncovering feature interactions among components are needed, especially for systems requiring a high level of safety and reliability.
When there are a large number of components with their variants and variation points and when there are complex dependencies among them, product derivation from this asset base is a very complex and difficult task. Future research should include developing knowledge-based approaches for product derivation.
Runtime dynamism is an emerging area of research in product line engineering. Computing environments such as service-oriented architecture and ubiquitous computing present new challenges. Product architectures and components must be configured autonomously while systems are running in these environments, requiring embedment of software engineering knowledge in the deployed systems. With these new environments, the focus of software engineering shifts from static development-time engineering to dynamic runtime engineering.
Non-technical issues as well as technical issues must be addressed to facilitate product line engineering to be adopted by the software development industry. Product line-based organizational structure, key practice areas and process models, and empirical research on return on investment are all areas requiring further research.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment