NEWS AT SEI
This article was originally published in News at SEI on: June 1, 2006
The SEI is hosting the 10th International Software Product Lines Conference (SPLC 2006) in Baltimore, Md., from August 21 to 24 at the Baltimore Marriott Waterfront. SPLC is more than a forum for research results: it provides a venue for the product line community to share discoveries, experiences, and questions. The research and applied software product line communities come together at SPLC to discuss problems, explore solutions, and establish collaborations. SPLC brings together the three product line constituencies—organizational managers, technical managers, and software engineers—to exchange ideas and interact.
Highlights of the conference are
- keynote talks by Carliss Baldwin of the Harvard Business School and Gregor Kiczales of the University of British Columbia
- speakers ranging from business-unit vice presidents to software engineers
- interactive panels, including one on product derivation and one on testing, where detailed model problems will be used to ensure in-depth discussion
- numerous opportunities for networking, including social events and several lively birds-of-a-feather sessions
The software product line strategy continues to bring about order-of-magnitude improvements to organizations in cost, quality, and time to market. With the maturing of the field, the following areas of concerns come into focus:
- production planning
- economic issues
- variability management
The SPLC is facilitating the interaction of product line professionals in these areas.
As a consultant to many large software development organizations, I have witnessed many spectacular failures. None was more dramatic than the efforts of one company that attempted to design a platform on which it planned to build several of its products. Multiple business units cooperated to fund and manage the platform development. By some measures, this effort was a technical success: The company produced an innovative architecture that promised to see its products into a fruitful new generation. Ultimately, however, the effort was a business failure. No single group or team within the company had control over both the platform and the products built from it. Individual product managers had incompatible objectives, while the schedule for incremental delivery of the platform satisfied none of the product teams. The platform team elicited requirements from the product teams, but no group explicitly considered how the product teams would produce products from the platform. The result? The platform was built, but because the organization had not planned for product production, no products were ever constructed using it.
As this failed effort indicates, production planning should occur before the core assets, much less the products, are produced. The planning should begin with development of a production strategy, which provides overarching guidance to the production-planning activity. This guidance should then be provided to the core-asset as well as product developers. The production strategy provides the basis for engineering the production method and the detailed processes, models, and technologies used to produce products. These two assets—the production plan and the production strategy—are essential inputs to the plan, which details how individual products are built [Chastek 02a, Chastek 02b].
SPLC 2006 will offer insights into product production and production planning.
- In his tutorial titled “Generative Software Development,” Krzysztof Czarnecki will describe one path to the automatic production of products. His approach uses feature-based modeling to specify a product.
- John Hunt will present his work on “Organizing the Asset Base for Product Derivation.” He will show the results of investigations into three techniques for organizing asset bases for optimal use in producing products.
- Kwanwoo Lee and his colleagues will present their work on “A Feature-Oriented Approach to Developing Dynamically Reconfigurable Products in Product Line Engineering.”
Product Line Economics
An essential step before adopting the product line strategy is to determine whether the product line approach is appropriate given the business and technical context of the organization. The rate at which products in a domain are changing, the size of products in the domain, and the degree of similarity among the products are some of the factors that affect the viability of the product line approach in an organization. The business environment, such as whether the company produces software for internal use or sale or under contract to government agencies such as the Department of Defense (DoD), also affects the factors that should be considered.
The product line community has developed several models that incorporate these factors into computations to determine the costs and benefits of the product line strategy in a specific context. For example, the Software Engineering Institute’s (SEI’s) Structured Intuitive Model of Product Line Economics (SIMPLE) is the result of a collaboration of several researchers and organizations [Böckle 03, Clements 05]. SIMPLE uses a core set of cost functions that guide the modeler in identifying and collecting the appropriate information for estimating the costs associated with the product line effort.
At SPLC 2005, a panel on economic models presented several approaches, including SIMPLE. At SPLC 2006, this topic will continue to be explored:
- Carliss Baldwin’s keynote talk at SPLC will explore how design architectures “affect economic incentives and patterns of competition over new products.”
- Dharmalingam Ganesan, Dirk Muthig, and Kentaro Yoshimura will present their work on “Predicting Return-on-Investment for Product Line Generations.”
- At the SEI reception on Wednesday evening, the latest version of the SIMPLE Web site will be introduced.
An organization that wants to effectively exploit the commonality among products (even as few as two of them) must be aware of, and be able to manage, the variation among them. Variation among products is integral to conducting activities that range from the initial scoping of the set of products that constitutes the product line to the design, implementation, and testing of those products.
Many problems related to variability management remain unresolved:
- No one notation has gained widespread acceptance for representing variation in product specification or design. Several feature-modeling notations are currently in use. The most widely used software-design notation—the Unified Modeling Language (UML)—does not have explicit facilities for representing variability.
- The task of physically managing all the specifications and implementations of product variants challenges existing configuration management (CM) practices. Many CM tools are unable to map a single asset onto multiple products.
- Variability arises at virtually every level of product development. For this reason, techniques are needed to establish traceability from the earliest identification of product variability through product implementation and testing.
- There are no widely accepted tactics for mapping the identified need for a variant to the appropriate mechanism for implementing that variation.
At SPLC 2006, several presenters will continue to pursue variability management:
- Klaus Pohl, Frank van der Linden, and Andreas Metzger will present a tutorial titled “Software Product Line Variability Management.”
- Paul Clements and Dirk Muthig will host a research workshop on “Managing Variability for Software Product Lines: Working with Variability Mechanisms.”
- Gregor Kiczales’ keynote on “Radical Research in Modularity: Aspect-Oriented Programming and Other Ideas” will look forward to new tools for implementing variation management.
What other enriching opportunities will happen at SPLC? I have no idea—but some are sure to. Often the most useful exchanges are those that happen in response to a question during a session or during an exchange between panelists, in a conversation at the conference reception, or during the breaks between sessions. The SPLC organizers are trying to provide an environment in which these encounters are encouraged and facilitated. Visit www.splc.net for the latest information on what we’ve planned and how you can register.
Böckle, G.; Clements, P.; McGregor, J.; & Schmid, K. “A Cost Model for Software Product Lines,” 310-316. Proceedings of the Program Family Engineering (5) Conference. Siena, Italy, November 4-6, 2003. Berlin: Springer, 2003.
Chastek, G. & McGregor, J. D. Guidelines for Developing a Product Line Production Plan (CMU/SEI-2002-TR-006, ADA406687). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.
Chastek, G.; Donohoe, P.; & McGregor, J.D. Product Line Production Planning for the Home Integration System Example (CMU/SEI-2002-TN-029, ADA408820). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.
Chastek, Gary & Donohoe, Patrick. Product Line Analysis for Practitioners (CMU/SEI-2003-TR-008, ADA421616). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
Clements, P. & Northrop, L. Software Product Lines: Practices and Patterns. Reading, MA: Addison-Wesley, 2002.
Clements, Paul; McGregor, John D.; & Cohen, Sholom. The Structured Intuitive Model for Product Line Economics (SIMPLE) (CMU/SEI-2005-TR-003, ADA441881). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005.
Software Engineering Institute. A Framework for Software Product Line Practice (2005).
About the Author
John D. McGregor is a visiting scientist at the SEI and an associate professor of computer science at Clemson University. He is the general conference chair for SPLC 2006 and a partner in Luminary Software, LLC—a software product line consulting firm. McGregor is coauthor of A Practical Guide to Testing Object-Oriented Software, (Addison-Wesley, 2001) and Object-Oriented Software Development: Engineering Software for Reuse (International Thomson Computer Press, 1992). He writes a bimonthly column on strategic software engineering for the Journal of Object Technology. He earned BS, MS, and PhD degrees from Vanderbilt University.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.