BIGLEVER NEWSLETTER: From the PLE Frontline
Getting Started with Product Line Engineering – A View from the Inside
Part 2: How to Build a Production Line
Greetings from Paul Clements:
In this newsletter series, I'm discussing BigLever's getting started approach and the hands-on three-day workshop at its heart. In Part 1 of the series, I outlined the general steps that we take during the three days, which includes establishing a hierarchical production line structure, traversing it, and building a production line for each node. In this installment, I'll expand on what that last step entails.
In BigLever terminology, a production line is the automated infrastructure for producing the products in a product line. Think of it as the factory, which takes lifecycle product assets (requirements, code, tests, or user manuals, to name but a few), exercises the variation points in those assets according to the features of a particular product, and produces instances of the assets appropriate for that product. Gears is the engine that translates feature choices for a product into the set of assets configured for that product.
The red outline shown in the illustration encloses the production line: Assets endowed with feature-based variation points, descriptions of products (called feature profiles), and Gears. (Click image to enlarge.)
The "real work" of a Getting Started Workshop, then, is to build the production lines along the way. Here's how it works.
At a Getting Started Workshop, someone from the customer organization always operates the Gears tool, not BigLever. We coach the "driver" regarding how to create a new production line: Set up the files and folders, create the base file, and so forth. Once this preliminary setup is done, our production line is built in three steps:
First, we elicit features for that product line from the participants.
You'd think this would be the step that, on a flowchart, would be labelled "Magic happens here," but in fact it's surprisingly straightforward. We ask, "How does this part of your system differ from product to product?" That's it. To our surprise and pleasure, the differences usually come pouring out. Those that signify distinguishing customer-facing characteristics are features.
Our Gears operator captures the features by building a feature tree -- essentially, a decision tree that lays out the choices that must be made to specify individual products. In a matter of minutes we have a nice feature model defined.
Then we ask which combinations of these features are useful, and our operator captures those as feature profiles. (An important point about feature profiles is that they prevent you from worrying about the often-astronomical number of feature combinations that you don't care about.)
Next we explore if there are any combinations of features that must always co-occur, or must never co-occur, and we help our operator turn those into feature assertions, which are a vital part of the domain knowledge. Finally, we ask our Gears operator to build a matrix for this product line, which is a Gears construct for specifying all of the choices associated with particular products.
Second, we turn our attention to configuring one or more assets by inserting variation points.
Each Getting Started Workshop has a focus (established during the preparation phase) on particular lifecycle assets. Requirements are a favorite, but code, user manuals, project plans, build scripts, test artifacts, and more also frequently play a role. This step involves working on the focused asset associated with the production line we just built.
Suppose the asset is a requirements specification, maintained in DOORS. We will comb the existing specification looking for places where it differs from specs for other products, or where it is product-specific, or where it attempts to be product-agnostic through "if" clauses. We then convert those areas to variation points, demonstrating the DOORS/Gears interface.
Third and finally, we actuate.
Actuation is the term we use for Gears configuring shared assets into product-specific instances, based on the feature profile for a product. Once we have an asset "wired up" with variation points expressed in terms of the features in our feature model, we add it to the production line's matrix, and the operator pushes the Gears "actuate" button for a product. We then examine the generated asset instances, to show that they are configured appropriately for that product. We repeat the actuation step for every product in the matrix.
For a workshop really "in the groove," we can accomplish this milestone by lunchtime on the first day.
In my final installment I'll explore some key observations about the getting started process and the insights that companies gain from this experience.
Dr. Paul Clements
BigLever Software Vice President of Customer Success
Don't miss your Newsletter!
Please help us make sure that you continue to receive the BigLever Newsletter by confirming your subscription with us. This ensures that future newsletters will be successfully delivered to your Inbox and not misplaced into your junk mail or spam folder. To confirm, simply click the "confirm" link in the white bar below. After confirming, you can unsubscribe from our newsletter distribution at any time.