Product Line Engineering Design

by

“We have 30 products in our product line with 5 variants of each product. We release every product variant 2 times every 18 months with about 30-45 new features in each release. A product contains 300 modules with 500 reusable objects per module. The release roadmap and mapping it to the requirements is a pain point.”
“Our current pain points are; Traceability analysis and baselining, Feature change management, and Product change management. We need to view requirement states across all releases.”
“Your PLE 2014 Design Hills and direction resonate well with our needs. We have been waiting for this solution for years”
“Very glad you are being intentional about minimizing impact to existing users and enabling users to adapt better reuse patterns for reuse incrementally — that’s critical. We can’t expec to start from scratch. This has to be accessible to our teams without heroic changes to how they are working now.”
After seeing the playback and our discussions at the Sponsor User call today, here are some quotes from my  team: “big leap forward”, “great progress”, “these demos can impress some of our executive people”
Read more about Strategic reuse and product line engineering in an article by Eran Gary, Distinguished Engineer, Rational Continuous Engineering.

In 2014 I was leading to the design concepts for Product Line Engineering in the IoT Continuous Engineering solution.

What is Product Line Engineering

The industry is making amazing IoT innovation in the products, systems, and applications that impacts most of our daily lives: from the smallest transistors in the latest microprocessor making the simplest THINGS smarter, to the most advanced products like cars, airplanes, transportation systems, city infrastructures and  globe-spanning electronic networks we now take for granted. Increasingly powerful yet inexpensive hardware, embedded and cloud-based software and ubiquitous network connectivity are enabling new levels of intelligence, interconnections and instrumentation.

The price we pay for this progress is increasing complexity in the designs, development processes, and supply chains needed to create these smarter products and systems. In many industries development teams are finding their old development processes and tools to be insufficient to meet the challenges. For example: Engineering teams in auto companies have traditionally focused on mechanical engineering; now the majority of the requirements they must address are expressed in software running on the many processors networked together in a modern car.
Smartphone device manufacturers employ an army of programmers to manage the torrent of monthly changes in the Android operating system and evolve their own proprietary value-adds. IT application development managers deal with extensive supply chains as they seek to optimize cost, quality and time to market.

The IBM continuous engineering solution is a set of engineering and development tools that help systems engineers, application developers, and embedded developers work together to create product lines of smart and connected products.

A product line strategy helps to address the timeless need to work faster, cheaper and better. For example:

  • Increase revenue by reaching more market segments / niches. Product variants provide targeted sets of capabilities, price points, and compliance with specific regulatory regimes.
  • Improve time to market and lower development costs. Products are defined as sets of reusable components in a product line.
  • Improve quality and lower field service costs. (A) Reusing validated and verified components already in the field results in lower defect densities and field service costs. (B) Engineering tools that can automate the reconstruction of complex product configurations used by clients will reduce field service costs through increased productivity of the engineers, for example, when preparing their environment to find and fix a defect.

A Product Line is a group of closely related products that are variants of each other. A product is formed from a specific configuration of component parts, often produced from a common base, or architecture, of components. Each component used in a product has associated requirements specifications, designs, software, test plans and more. These artifacts are linked Requirements are linked to the design artifacts at system and subsystem level that model the requirements. The design is linked to the implementing code. Tests are linked to the requirements and code they validate. The links declare dependencies and enable traceability and impact analysis.

artifact traceability

However, the requirements specifications of each product in a product line is slightly varying. For example a Compact car has different product requirements as compared to a Premium car. As the requirements specifications are different all downstream artifacts like designs, software, test plans are also impacted.

“Product lines are a development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and flexible response, and provide a capability for mass customization” – Software Product Line handbook by SEI

A common approach to manage the variability is to use a ‘Clone and Own’ practice. When stating developing a new product variant a copy is made of all requirements specifications, designs, software, test plans and other associated artifacts. Requirements specifications for the new product variant are modified or added in the copy. Requirements specifications that do not apply to the new variant are removed. All downstream artifacts and traced and updated in a similar way. While this approach is simple and pragmatic it is ineffective. It is challenging to share components across products and leverage improvements made in one product variant with other variants. Defects has to be coordinated and fixed in every variant individually by each product team. The use of development resources is also ineffective. A system engineer, a system developer or a tester can not easily switch tasks between project variants. Recreating a development environment with a complete and accurate set of requirements, designs, code, and tests is highly manual and can easily take several hours. Making sure that the environment is correct and consistent with latest state of all versions is challenging and tedious.

product variants

A more effective way of working would be to offload the challenge of variants and configurations to the development tools. Imagine a tool that would manage all requirements, designs, code files, and tests and a structure representing each reusable component in a product, including the system, subsystem, SW and HW levels. Then, imagine that each of the components have be branched into variants. The tool would manage the changes made to artifacts in each component variant. And then finally, imagine a way to select what variant of each component that would be used by each product variant in a product line. That would be so cool! And as a practitioner, I would be able to just ‘ask the tool’ to present me with the right artifacts for each component by choosing the product variant I wanted to work with. And, then, when ‘asking the tool’ to switching to another product variant the tool would transparently just present the right artifacts of the new variant. Just like that, switch configuration in seconds. That simplicity of operation and assurance of correct artifact version is the value proposition to enterprise sized systems delivery organizations that is challenged by the market demands of delivering product variants and inefficiency of managing the development of the product lines.

Artifacts, like the products they describe, have versions. A version of an artifact is identified by a specific set of characteristics and can exist at the same time as other versions of the artifact in other configurations. Artifacts are contained by components to make them easily tracked and reused. Product line engineering adds configuration management to enable System Engineering teams to effectively work on changes for a given product variant.

PLE design strategy

Our objectives are to design PLE by adding capabilities to our existing Application Lifecycle Management tools and articulating best practices, rather than creating a new PLE tool

PLE aspects concerns the entire development process.  This strategy focuses on the supporting infrastructure for artifact management and reuse needed to support PLE practices.

  • Specifying a multi-domain product structure – What is exactly the product?
  • Consistently manage asset versions and product configurations across all lifecycle disciplines – Create cross product baselines
  • Effectively handling change propagation to multitude of variants – Where does this change need to go
  • Effectively creating new product configuration based on functional parameters – What features define my new product variant

This strategy enables

  • Product development teams to
    • Achieve high levels of reuse and parallel development
    • Define and work in the context of the products and components they are developing
    • Engineer product lines
  • Work across engineering domains
  • Employ version and configuration management across these domains
  • Federated data that is created and managed by multiple tools from multiple vendors
  • Use open standards and specifications
  • Enterprise scale with world-wide teams

Hills

My research and analysis led our design to two key System Engineering personas and two PLE hills

Hill 1. Teams enjoy configuration management in and across their ALM tools

  • With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.
  • Configuration Leads can define configurations of a product under development consisting of requirements, tests, designs and implementation.
  • Teams work in a scalable environment with 1000s of configurations consisting of artifacts managed in multiple tools and links within and across those tools.

plehills1

Subhill 1.1 Fine-grained components in RDNG and RQM

Subhill 1.2 Impact analysis using validity assertions

Subhill 1.3 Report from the lifecycle index with versioned data from GCM, RQM, RDM, RTC, including using data currently missing and data related to plans and project areas

Hill 2 – Technical foundation

Provide and adopt service additions for multi-stream configuration management in Foundation, DNG, RQM, RTC and DM

  • Provide and adopt a Global Configurations SDK
  • Provide and adopt Link service
  • Enable configuration-aware aware dashboards and product artifact views, including document generation and TRS data feeds in RQM
  • Enable configuration-aware TRS data feeds in RDNG, RTC, DM and fill the data gaps in RTC, Foundation
  • Provide and adopt validity service

Use-Cases

Product Line Engineering capabilities should enable development organizations to

  • Decompose products into (independent) reusable components, like requirements modules, test plans, and design packages or blocks
  • Develop new products by reusing and modifying components
  • Develop and release a platform of reusable components that can be combined into new variants of products
  • Develop and release components of related requirements, tests, designs and implementation into a reusable global configuration component
  • Re-factor artifacts across components within the same project area, split and merge components within the same project area.
  • Work in parallel when developing, releasing and using variants of reusable components
  • Compose products under development from both released immutable component baselines and mutable component streams
  • Overview the product, its parts, and the component configurations
  • Select a product configuration context, and then work, either collaboratively or in isolation, on changes in and across multiple component
  • Deliver or merge changes made in one component configuration to other component configurations
  • Report on components and their metadata, configurations and their metadata, and the artifacts in a configuration

The Product Line Engineering hills call out two major use-cases

  • The Configuration Lead creates a new product configuration
  • The System Engineer switches into and starts working in the context of the new configuration
Use-Case – Create a new product configuration

plehills3

Use-Case – Switch and work in a context

plehills2

PageLines