BIGLEVER NEWSLETTER: From the PLE Frontline
Paul's Three Surprises
Greetings from Paul Clements:
I joined BigLever in early November, 2011. For the previous 17 years I was in the Product Line Systems Program at Carnegie Mellon University's Software Engineering Institute. I started writing about product lines in the mid 1990's, helped create the SEI's Product Line Practice Framework, helped launch the Software Product Line Conference (SPLC) series of international conferences, and co-authored a book about software product lines.
I came to BigLever with the conceit that, although there's always more to learn, I knew a thing or two about product lines. It's been fun to see where my notions have stood up and where an adjustment has been in order.
Welcome to my newsletter series on three of the most delightful surprises I've found since coming to my new professional home.
#1: Product line engineering is not just about software.
I learned about product line engineering in the software product lines community. Imagine my surprise to learn that for many organizations building product lines, turning out configured source code is not at the top of their priority list – if it's even on the list at all.
For example, many BigLever customers list requirements management as the biggest pain point in their product line engineering. For those organizations, the big win comes from inserting feature-based variation points into their requirements assets, and then using BigLever's Gears solution to exercise those variation points to produce product-specific requirements.
This big win was demonstrated recently with one of our customers, a major defense contractor and long-time supplier of a major weapons system for one of the services. When a different service procured a version of this weapon system, instead of cloning a copy of the requirements and manually adapting it – which was the standard practice in the past – they were convinced to join the product line family, select the features of the system their version would exhibit, and let Gears turn out the requirements for it. Instead of 3 - 4 months expected under the clone-and-own method, their requirements were vetted and ready to support development in 2 weeks.
Another customer, a global leader in automotive manufacturing, has prioritized requirements, design models, supplier specifications, calibration packages, and other assets ahead of the software in their product line plan. In fact, they've told us that over and above producing these product-configured assets, one of the key early benefits they anticipate has nothing to do with configuring any asset for any product. It's simply having a full, complete, consistent, top-to-bottom model that captures all the variation in their product line, using a consistent feature model and consistent variation point language in assets from one end of the engineering lifecycle to the other. This company's product line supports tens of thousands of product variants and several million product copies, each one of which runs millions or tens of millions of lines of code. Bringing the product line diversity in that engineering process (animated by some 5000 engineers) under top-to-bottom control represents an enormous payoff.
These and other lessons are why we no longer think of ourselves as just in the software product line business, but rather the more-encompassing product line engineering business.
We are about the production of a portfolio of related products using a common set of shared systems and software engineering assets and a common means of production. The products in the portfolio are described by the features they have in common with each other and the feature variations that set them apart. Throughout the full engineering lifecycle, a product is represented by a set of assets that have been configured based on features. If the product contains software, then the software numbers among the assets. But even non-software products have soft assets: requirements, design models, user documentation, supplier specs, test cases, development plans, project budgets, and much more.
So, surprise: No software? No problem.
That was a surprise to me, but not the biggest. That's coming up in a future issue of our newsletter.
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.