SPLC 2004 will host three conference panels:

Product Line Binding Times: What You Don't Know Can Hurt You
Avoiding, Surviving and Prevailing Over Pitfalls in Product Line Engineering
How Can Testing Keep Pace with Accelerated Development in Software Product Line Engineering?

Product Line Binding Times: What You Don't Know Can Hurt You
Panel Moderator: Charles W. Krueger, BigLever Software, Austin, TX, USA

Panelist
Dale Churchett, Salion, USA
Jan Bosch, University of Groningen, The Netherlands
Jim Snyder, Coremetrics, USA
Rob van Ommering, Philips, The Netherlands
Krzysztof Czarnecki, University of Waterloo, Canada
Joe Moore, Engenio Information Technologies (formerly LSI Logic Storage Systems), USA

Abstract
Choosing the right variation binding time–the point in the software engineering process at which decisions for variation instantiation are made–is often one of the most critical, most contentious, and least well understood issues for software product line organizations. This panel explores some of the fundamental binding time issues and insights based on the research, best practices, and real world experiences of the panelists.

Overview
One of the most critical, most contentious, and least well understood issues in a software product line approach can be the selection of the optimal binding time(s) and associated binding mechanism(s). There are often different agendas for the different stakeholders, plus preconceived and possibly inaccurate ideas about software product line engineering that can lead to strong differences of opinions about how to go about implementing a software product line. The goal of this panel is to expose the fundamental issues, myths, and hidden agendas surrounding binding time selection.

The essential distinction between software product line engineering and conventional software engineering is the presence of variation in some of the software assets. In the early stages of the engineering process in a software product line approach, software assets contain variation points that represent unbound options about how the software will behave. At some point during the production process, the decision model is used to select among the options for the variation points. Then the behavior of the variation point in the final product is fully specified.

The time at which the decisions for a variation point are bound is referred to as the binding time, and the means by which the decisions are used to instantiate the variation points is referred to as the binding mechanism. Examples of binding times include source reuse, development, source instantiation, build, package, install, start-up, and execution time. Examples of different binding mechanisms include language templates, manual production, preprocessors, off-the-shelf product line tools, build scripts, CM views, installers, config files, and language conditionals.

Some of the questions and issues addressed by the panel include
1. What makes binding time selection a critical decision?
2. What are the criteria for selecting among different binding times? How do you identify the optimal choice?
3. When is it appropriate to use multiple binding times?
4. What are the different stakeholder agendas, and which ones can be detrimental?

Avoiding, Surviving, and Prevailing Over Pitfalls in Product Line Engineering (panel slides)
Panel Moderator: Charles W. Krueger, BigLever Software, Austin, TX, USA

Panelist
Jim Dager, Cummins, USA
Ulf Olsson, Ericsson, Celsius Tech (now Saab Tech)
Anders Heie, Nokia, USA
Martin Verlage, MARKET MAKER, Germany
Bill Hetrick , Engenio Information Technologies (formerly LSI Logic Storage Systems), USA

Abstract
In this panel, pioneers from some of the software product line field's best-known success stories share their experiences on how to detect potential pitfalls, how to avoid looming pitfalls, how to survive pitfalls that are unwittingly encountered, and how to turn the negative aspects of pitfalls into positive advantages.

Overview
It is inevitable that with every software product line success story, a little rain must fall. In retrospect, stories about the trials and tribulations that arise along the way to a software product line success can provide insight, guidance, education, portent, inspiration, and even entertainment.

This panel is made up of key leaders from well-known software product line success stories, sharing how they

• avoided the pitfalls that they were insightful enough–or lucky enough–to perceive before it was too late
• survived the pitfalls that surprised them along the way and how, in hindsight, they might have detected and avoided them
• prevailed over unavoidable pitfalls, turning negatives that could have doomed their efforts into positives that worked in their favor

The audience is encouraged to ask the panel for insight about specific pitfalls they have encountered.

How Can Testing Keep Pace with Accelerated Development in Software Product Line Engineering?
Panel Moderator: Birgit Geppert, Avaya Labs Research, Basking Ridge, NJ, USA

Panelists:
Carl Shaulis, Salion, USA
Henry Muccini, University of L'Aquila, Italy
Tim Trew, Philips Research Laboratories, UK
Claudia Fritsch, Bosch, Germany
Ronny Kolb, Fraunhofer Institute, Germany

Abstract
This panel explores the topic of software product line testing. Techniques for accelerated product development are widely published, but what are the implications to product testing in a software product line organization?

Overview
Although many organizations have reported ways in which software products can be created at a greatly accelerated pace using software product line techniques, little has been reported about the testing of those products. How do the test groups within these organizations keep pace with the accelerated product development?

This critical question is asked frequently by organizations considering the move to software product line engineering, particularly as they do their return-on-investment analysis. Without a convincing argument that testing can achieve similar accelerators, testing looms as the limiting bottleneck, making it appear that the test group must scale its expensive resources to support brute-force testing of all the new products rather than scaling the efficiency of its existing resources.

This panel brings together software product line test practitioners and researchers to shed light on this important topic and to address the following questions and more.

1. Is brute-force scaling of testing resources sufficient for software product line testing? Is it necessary?
2. The two guiding principles in software product line development are (a) capitalize on commonality and (b) formally manage variation among the products. Do the same principles guide software product line testing?
3. Conversely, are there other and possibly more important guiding principles that are unique to product line testing?
4. Is the variation space for development and testing the same? Can we leverage results from earlier development phases (such as decision modeling) for testing?
5. Are there additional problems that come up when dealing with variabilities that might even hinder/slow down testing?
6. Domain engineering of core assets is the prominent activity in software product line development, with significantly less effort dedicated to application engineering of the individual products. Intuitively, it seems that testing requires the opposite balance: more effort on integration and system testing than on unit testing. Is this true? How do you find the appropriate balance?
7. How much does improved product quality reduce the testing burden?