Product Development & Management

Feature-based Product Line Engineering: Translating Engineering Gains into Strategic Business Value (Part 2)

By |

This article is Part 2 of a two-part series by our friends at BigLever Software.

Part 1 provided an introduction to Feature-based Product Line Engineering (PLE) and the “PLE factory” – which is a foundational concept in the new PLE ISO standards under development, as well as the underpinning of BigLever’s PLE approach.

As a reminder, PLE is an innovative engineering practice that provides a way to take full and ongoing advantage of the commonality shared across a product family, while efficiently and systematically managing the variation or differences.

In this article, we will take a closer look at the underlying concepts central to Feature-based PLE — the automated production line approach enabled by PLE — and the supporting technology foundation.

The PLE Automated Production Line

As discussed in Part 1, the underpinning of PLE is the PLE factory, which is much like a typical manufacturing factory except that it operates on digital assets rather than physical parts.

PLE allows an organization to create a “superset” supply chain of digital assets that can be shared across the entire product line. These digital assets are equipped with all the feature options offered in the product line.

Figure 1 provides an extended view of the PLE factory and how it enables the establishment of an automated production line that assembles and configures the shared digital assets based on the features that are selected for each product variation – enabling a fully unified, automated approach.

Figure 1: The PLE automated production line

Feature-based PLE enforces consistent treatment of all shared assets under the automated production line infrastructure, so that a full set of demonstrably consistent supporting artifacts can be systematically generated for each product.

Assets are designed in Gears, BigLever’s industry-standard PLE solution, with built-in variation points. Each variation point describes a piece of content in the shared asset whose participation in any product depends on a certain feature, or combination of features, being chosen.

When a product is built, the configurator uses the product’s feature-based description to “exercise” these variation points (that is, configure the asset to meet the needs of the product.)

Variation point mechanisms comprise: including or omitting the artifact; choosing one variant of the artifact (from an available set) to use in the product; or making fine-grained choices within an artifact such as including or omitting a requirement, section in a document or model element or block of code.

Under this shared-asset-with-variation-points paradigm, the artifacts that engineers create and maintain for the product line are supersets: Each has the content necessary to support any product in the product line. The configurator’s job may be seen as exercising the variation points to filter away content until only that needed for the product being built is left.

Variation points are expressed in terms of features, not products. The configurator does its work by comparing feature-based expressions that define a variation point to the feature choices that define a product.

Hence, the assets are configured to support feature selections; the supersets become product-agnostic. Among other benefits, this makes adding a new product to the portfolio exceptionally easy.

Figure 2 provides a closer look at the classic engineering V-model, recast for product line engineering.

Figure 2: Engineering V-model and PLE

Each phase across the lifecycle is augmented by the addition of variation points (indicated by the gear symbol) to the artifacts native to that phase.

A Bill-of-Features for a product, as shown at the top of Figure 1, corresponds to the feature selections within the feature profiles for that product. The yellow arrows illustrate that all of the variation points in all of the artifacts across the full lifecycle are synchronously and consistently configured according to the single consolidated collection of feature selections in the Bill-of-Features.

Gears and the PLE Ecosystem

As the technology foundation for the PLE factory, Gears is the all-in-one tool used to establish, organize, and operate an automated production line. More specifically, Gears provides the means to:

  • Create and maintain the production line
  • Build and maintain the feature catalog and Bills-of-Features for the production line
  • Attach shared assets to the production line
  • Edit shared assets to define variation points and create instructions to Gears for how to exercise them
  • Configure the shared assets to produce product-specific instances based on a Bill-of-Features

In a PLE context, requirements engineers work on requirements, software engineers work on software, test engineers build test cases, assembly engineers build bills of materials and parts lists, tech writers create user manuals, build engineers craft build scripts, and so forth. While these activities now happen in the context of the entire product line rather than individual products, the individual engineer’s job, by and large, remains the same.

However, under the PLE factory approach, we need the requirements engineers, software engineers, test engineers, and the rest to put variation points into their artifacts – and we want that process to be assisted and facilitated by automation that will eventually exercise those variation points. This means we need a way to support the specification and selection of variation in assets and artifacts from across the entire lifecycle. This is enabled via the PLE Ecosystem of tools and Gears Bridge integrations with those tools.

The PLE Ecosystem was established to allow engineers to continue to work in the technology and tool environments to which they are accustomed, while making those environments “product line aware”.

Tools in the PLE Ecosystem may be commercially available, open source, customized, integrated or proprietary. This PLE Ecosystem is important for ensuring that these tools work effectively with Gears for a consistent, compatible, fully unified PLE solution across all enterprise lifecycle phases.

Gears interfaces with the tools in the PLE Ecosystem via integration bridges. Built on the PLE Bridge API, Gears Bridge solutions make tools product line aware by incorporating standardized variation point mechanisms and enabling the execution of PLE operations – such as product configuration, variation point editing and variation impact analysis – from within the tools.

Figure 3 illustrates Gears Bridge integrations using examples of shared asset types and tools.

Figure 3: Bridge integrations via the PLE Bridge API

The PLE Ecosystem includes tools from third-party tool providers such as IBM Rational, Aras, PTC, No Magic, Sparx, Microsoft, Perforce, MadCap, Open Source and more.

The PLE Bridge API also enables organizations to create bridges for connecting with additional engineering tools that are used in their tooling environment. The PLE Ecosystem continues to grow as BigLever, our partners, and our customers add new integrations and strengthen the capabilities of existing ones.

Engineering Gains Translate to Business Value

In this article series, we have explored how Feature-based PLE is not a “boutique” hand-crafted approach, but is proven, robust, and industrial-strength — centered around the factory paradigm and backed up by industrial-scale commercially available tooling.

We see this leading-edge approach being used by forward-thinking organizations to achieve dramatic reductions in the overall engineering effort required to design, produce, deliver and evolve their product lines. This, in turn, translates to major cost savings.

For example, Lockheed Martin reports an average of $47 million in annual cost avoidance using Feature-based PLE to produce the AEGIS Weapon System product line for the U.S. Navy.1 And another global aerospace defense company accumulated more than $746 million in cost avoidance based on its PLE approach for the production of the U.S. Army’s Live Training Transformation product line.2

These engineering efficiency gains and cost savings translate to major strategic business value for organizations employing Feature-based PLE — including order-of-magnitude improvements in time-to-market and product quality, increased product line scalability, and ultimately, a greater competitive advantage.

Note: Is your company interested in a BigLever and Jama Software integration? Let us know! We’re exploring the creation of a new Gears Bridge solution for Jama and looking for early adopters. Contact BigLever at [email protected].

[1]  Product Line Engineering on the Right Side of the “V” by Susan P. Gregg, Denise M. Albert, and Paul Clements, Proceedings of the 21st International Systems and Software Product Line Conference (SPLC 2017), Sevilla, Spain. September 2017.

[2]  “Training and Simulation,” https://gdmissionsystems.com/c4isr/training-simulation/.

Latest posts by BigLever Software (see all)