This post is part of a 3-part series on Product Line Engineering in collaboration with PLE experts BigLever Software. Read all 3 parts of this post series to gain insights into the framework and practice of feature-based Product Line Engineering and to understand how PLE can help you facilitate the development of complex product lines with multiple product variants!
Missed parts 1 & 2? Catch up:
Your Guide to Modern Product Line Engineering | PLE Part 1/3
Understanding Feature-based Product Line Engineering | PLE Part 2/3
In Part 1 of our blog post series on PLE, we gave an overview of the fundamentals of Product Line Engineering. Part 2 introduced the concept and benefits of Feature-based PLE. In this last post, we’ll cover the practical aspect of implementing feature-based Product Line Engineering in your organization! Read on to understand the building blocks of this framework, and for practical guidance on introducing PLE to cut the costs of managing complex product lines.
As established in previous parts of this series, we’re experiencing the rapidly growing complexity of both individual products and the product families they are part of. Developers are innovating more and more product variants, each with increasingly sophisticated software components. This results in a growing need for efficient means to produce these systems and product lines. PLE promises to help decrease development costs and time to market by adopting a factory approach to building complex product lines.
Building blocks of a feature-based PLE factory
The fundamental elements necessary for a proven and repeatable Product Line Engineering process are defined by the ISO 26580 standard (Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering). The concept laid out by the standard is best explained by the following illustration:
INCOSE – Feature-based Systems and Software Product Line Engineering: A Primer
The factory approach to PLE uses the following assets to serve as the basis for all product line engineering efforts:
Shared assets: These artifacts are common across the product line. They are used to support the design, implementation, deployment, or operation of products. Each shared asset is maintained as a superset with variation points. The superset contains all the material necessary to cover all of the products in the product line. Variation points are pieces of content within a superset that only apply to some products, depending on selected features. These supersets help eliminate the need for any duplication of engineering content. Learn more about shared assets in the following section!
Feature Catalogue: Quite literally, the feature catalogue is a catalogue of features that are available for each product variant. When designing the product, you’ll just pick a feature from this catalogue, and apply that to the specific variant being produced. Upon applying this selection, variation points from the superset will be configured to fit the needs of the product being developed. As a result, stakeholders will have a common language and a clear definition of the product line’s scope of variations.
Bill-of-Features: As the name implies, the Bill-of-Features specifies all the features selected for each product in the product line, providing clarity in how your product line is built up.
PLE Factory Configurator: The PLE Factory Configurator is, in essence, a software tool that applies the Bill-of-Features to all of the Shared assets as defined above. By analyzing variation points, this Configurator is able to determine whether a variation point’s content will be included in a product, providing valuable input for production.x
Product Asset Instances: These instances contain those shared assets that pertain to each product in the product line. Essentially, these may be considered the output of the entire PLE Factory: Product Asset Instances contain the complete set of artifacts that constitute the product variant in question.
When compared to the traditional clone-and-own approach to PLE, the conceptual change here results from the Factory framework. Instead of building products and creating product variants like you used to, this approach has your teams focus on building the PLE Factory itself.
It is this Factory that enables the efficient management of product variants, while any and all changes to each variant are managed using a systematic procedure. Whenever needed, engineering assets are instantiated instead of being manually recreated again and again. This results in a repeatable process that yields great efficiencies when managing complex product lines.
Shared assets in a PLE Factory
Let’s take a quick look at the shared assets most often seen in a multi-product environment. While these are widely used, they are by no means the only shared assets: in fact, any digital artifact is a candidate to be a shared asset in a PLE Factory.
Requirements
The requirements superset contains all the requirements across the product line – product variations are then achieved through variation points. Whether a requirement is included in a specific product or not, how the requirement is worded, and whether any mutual exclusions are defined – all these are established by variation points. If there are no variation points for a requirement, that means the requirement is part of each and every product in the product line.
Models
In a PLE Factory, models work much the same way, developed as supersets and applied via variation points.
Hardware: Electrical and Mechanical Designs
The PLE Factory applies a range of shared assets to facilitate the production of electronic, mechanical, mechatronic, and cyber-physical systems. Supersets of parts, properties, and relationships define assets for Electronic Design Automation (EDA), Mechanical Design Automation (MDA), and Computer-aided Design (CAD).
Software: Source code
In the context of software systems, shared assets include source code, models, build files, and automated unit tests. The difficulty here is that software features may be closely integrated with the system’s specific software, electrical, and/or mechanical components – but they may also traverse these boundaries, meaning that a software system can affect several different modules. That’s why taking a modular approach to defining software architectures can be greatly helpful here, but you can make the PLE Factory approach work without this as well.
Test Plans and Test Cases
Whatever type of system you’re developing, you’ll be using testing artifacts (test plans and test cases) for V&V (validation and verification). Whether you are applying manual or automated testing strategies, the concept of supersets applies just the same (e.g. testing differences across product variants will be defined by variation points). This helps cut down on the amount of redundant testing, and helps ensure comprehensive testing: by automatically selecting the applicable tests from the superset, you won’t test content that’s not in the product, and you won’t fail to test content that is.
… and more
Shared assets in a PLE Factory aren’t limited to the types defined above. Assets like budgets and cost models, user manuals or other types of documentation, wiring diagrams or other engineering models and drawings, product descriptions, and other artifacts also benefit from taking the PLE Factory approach.
Adopting PLE in your organization
The benefits of a Factory approach to Product Line Engineering are clear, and are evidently larger as the number of product variants grows. But adopting the framework can be a challenge. As should be evident after understanding the PLE concept and assets explained above, implementing the framework means a much larger change than just installing a new tool or investing in training for your product teams.
Making Feature-based PLE work requires an organizational change that affects everyone working in product-related roles. Software architects, test engineers, but even technical writers are affected. Their focus will shift from developing individual products to managing a shared system of supersets and operating the PLE Factory.
This requires an organizational change that is more cultural than tangible. All stakeholders must adopt a product line-centric perspective, which requires a pervasive change in company culture that must be driven by leadership commitment.
Challenged by the development of sophisticated product lines with complex systems? PLE is one approach you should consider. Systems Engineering is another one that could help! Check out our primer to Systems Engineering:
