The main focus of this task is to describe for each of the roles their key PLE use cases. This is critical for mapping the use cases to the PLE solution.

PLE use cases include:

• Manage Product Line
• Define Product Variant
• Analyze Product Variant Dependencies

We prepare for the PLE use cases by defining strategically reusable items for the business.

A critical element of PLE adoption is to identify the size and shape of the reusable item for the product line. We will refer to the reusable item as a “component”.

• Search/Evaluate Component
• Reuse Component
• Provide Component Feedback
• Approve Component
• Publish/Update Component

Before defining each of these use cases it is important to define the intended consumer, and artifacts, links, and meta-data needed for the component to be reused effectively. There needs to be sufficient supporting material such as validation tests, opinions from other consumers and programs, defect logs and so forth, to build the trust necessary for the component to be reused.

A sample component structure definition is illustrated below. This is important to PLE adoption because the product line engineering activities will benefit by reusing components both within products and across products.

In the image below is a sample component based on the structure defined above. While not all items in the component are illustrated, it is important to note the kind of information needed for reusable components; namely, the location of and version (or baseline) of the artifacts for the component. This sample component below has a type declared, in this case it is a “System Requirement Component”, and as such it has requirements, and models, and interfaces and related tests but no code. Again, this is just a sample, but this is what is meant by the size and shape of the components; define their kind or type and the artifacts, meta data, and relationships which comprise them.

The other key item to address at this time is to make component versioning decisions. The version of a component is managed above and separate from the version of the artifacts in the component.

Refine as needed each of the use cases below.

Search/Evaluate Component

Pre-conditions:

1. Approved components are available.
2. Context (environment) within which component must operate is understood.

Roles: Product Line Manager, System Engineering Lead, System Engineer

Flow:

1. Provide criteria for operating context and functional behavior.
2. Browse components.
3. Evaluate impact to project if component is (re)used in that project.

Post-conditions:

1. Component(s) selected.
2. Feedback provided for capabilities/components not found.

Reuse Component

Pre-conditions:

1. Component selected which meets operating context requirements.
2. Support/maintenance model for reusing the component is understood.

Roles: System Engineer

Flow:

1. Component artifact baselines are brought into the project.
2. Variables, parameters and other configurable items are provided.

Post-conditions:

1. Component(s) selected.
2. Feedback provided for capabilities/components not found.

Provide Component Feedback

Pre-conditions:

Roles: Any

Flow:

1. Provide description of experience finding, understanding, and reusing the component, as applicable.
2. Provide suggestions for improvement, as applicable.

Post-conditions:

Publish/Update Component

Pre-conditions:

1. A component specification has been created for the component version.
2. All relevant baselines/versions for the resources are prepared.
3. Support/maintenance terms have been established, as necessary.

Roles: System Engineer

Flow:

1. Collect the relevant meta data (e.g., description, type, state, …) for the component.
2. Determine the component’s version.
3. Submit the component to the product catalog.
4. Notify interested parties (e.g., subscribers, previous component version users, …) of component version.

Post-conditions:

1. Component is visible to necessary stakeholders for review.

Approve Component

Pre-conditions:

1. Component is prepared for review.

Roles: Product Line Manager, System Engineering Lead, Subject Matter Experts

Flow:

1. Review stakeholders evaluate component’s ability to be reused in the intended operating context.
2. Review stakeholders evaluate component’s discoverability and understandability for potential consumers.
3. Review stakeholders indicate approval/rejection of component.

Post-conditions:

1. Upon approval, component is put into a state where it can be discovered, and reused.