Workshop Program Information

The format of the workshop will be highly interactive and collaborative. Participants will work in plenary and in working teams on the following:

1. Crafting a statement of need. Participants will discuss whether and why a standard is needed, and capture that discussion in a succinct statement. To stimulate and guide discussion, we will provide an initial statement of need, such as the following: “We need a way to establish that there is a community consensus concerning what constitutes effective product line engineering, what systems, software, and business problems it addresses, and what business and engineering benefits it provides. Following that, we need to capture and communicate that consensus in a usable way.”
2. Brainstorming a list of scenarios that express how a product line standard would be used by various segments of the community. Example scenarios include:
   • “Provide evidence to tool-builders that product line engineering is a viable, legitimate approach worth of investment in tooling, training, and services.”
   • ”Provide a teaching aid to the processes and practices that constitute effective product line engineering.”
   • ”Use as a model to provide guidance to and pedigree for methodologists, consultants, and trainers.”
   • ”Serve as a reference model for people to adopt product line engineering as their development paradigm.”
   • ”Serve as a reference model for product line practitioners to improve their practices.”
3. Brainstorming a list of requirements for the standard, so that the uses envisioned above can be achieved. Example requirements include:
   • ”It should have a strong community pedigree; that is, it should be seen as impartially capturing community-wide consensus.”
   • ”It should be usable to discriminate between sets of systems that are true product lines (that is, resulting from product line engineering) and those that are not.”
   • ”It should admit various specific product line engineering approaches now in use as being compliant.”
4. Discussing the possible form and content of the standard. Possibilities include:
   • a process model (describing artifacts, activities, and roles)
   • a conceptual entity-relation framework (such as found in IEEE-1471-2000/ISO-42010)
   • a compilation of proven practices.
5. Discussing and enumerating practices we want the standard to rule out. For instance, the standard should be such that any product set built using clone-and-own techniques would not be compliant.
6. Discussion of next steps. In particular, the participants will be asked this question: “Based on your work today, what needs to happen to produce a standard satisfying the intended uses we listed?”

We envision three working groups. One will discuss a set of “capturable” product line proven practices, one will discuss a process model for product line engineering, and one will discuss a conceptual framework for product line engineering.