Cross-Project Working-Sets and Variant Management

Introduction

This scenario assumes there is a customer project team that is supposed to develop a product according to the customers requirements. There is an existing product platform that covers the customers requirements at least to some extent and is supposed to be used to deliver a solution for the customer.

The concept is based on Composite Working-Sets extending the ability to define composite Working-Sets based on Working-Sets in different projects and highlighting the aspect of managing a customer project separated from the platform.

Figure 1: Initial Situation

Managing Customer Projects in codeBeamer

Including the Platform

To start the work based on the platform the customer project team will include the platform into the customer project making the platform accessible in the customer project including all relevant artifacts and traceability.

In this example the Default Working-Set of the platform project is included as "Customer Working-Set" into the Default Working-Set of the customer project.

Generally it shall be possible to use non-default Working-Sets too, to support the use cases where multiple versions or variants of a platform or customer projects need to be managed in parallel.

In most cases the customer project will include

• a baselined stable version of the platform or
• a Working-Set representing a specific release stream of the platform or
• a combination of both

and not the current head.

Figure 2: Re-Use Platform into Customer Project

Working in the Customer Project

The customer project team will be able to work on the re-used platform in the customer project independently.

On a very high level the goal is to allocate all of the customer requirements to requirements in the customer project and in the end provide a working and tested product that fulfills the customer requirements.

To be able to allocate all customer requirements it might be necessary to add or modify existing platform requirements or add new requirements specifications e.g. for components that are required additionally.

Test cases and Test Sets need to be adjusted according to added and modified requirements, same applies to other downstream artifacts like models or the actual implementation of the product.

Results of Test Execution are tracked in the customer project, how test results can be re-used in scope of different customer projects or after execution in the platform project is out of scope for this concept.

How the changes in the Working-Set are implemented is out of scope for this concept, but based on Working-Sets a feature based or a parallel development process could be established.

More information on those approaches can be found here: Working-Set Use Cases

When re-using an Working-Set from a different project there are two fundamentally different approaches:

1. Include the Working-Set into the project.
2. Share the Working-Set into the project.

With both approaches the included Working-Set will provide:

• Easy access to the re-used Working-Set.
• Bi-directional traceability between the re-used and re-using Working-Set.

When including the Working-Set a new copy is created in the target project. The team of the target project will be the owner of the copy and will get full read and write access to the copy.

When sharing the Working-Set the existing Working-Set is made available in context of the target project without creating an independent copy.

Both approaches can be combined by including some trackers of the reused Working-Set while sharing others.

An illustration of including a Working-Set can be found below. See Figure 5: Shared Variant for a illustration of a shared Working-Set and Figure 6: Hybrid Variant for a hybrid Working-Set.

Figure 3: Include Platform into Customer Project

Merging Changes into the Customer Project

It is possible that the platform is extended in a way that is relevant to the customer project after the platform has been reused into the customer project.

If that's the case the project team is able to pull in the changes in the platform using the existing merge functionallity.

Merging Change Back to the Platform

In case changes implemented in a customer project are potentially relevant for other customer projects those changes should be transported back into the platform.

In most cases the customer project team will not be able to working in the platform project, therefore the customer project team will create a merge request with all relevant changes that the platform team is able to review and incorporate into the platform.

Managing Customer Projects With a Variant Management Tool

When working with a variant management tool, all reusable parts of the product are managed in the platform project, the variability should be prepared there by the team managing the platform. Artifacts like requirements and test cases are tagged to be relevant for a specific combination of features and will be included only if the feature selection during variant creation does match the selection criteria. Furthermore the variant management tool can replace content in artifacts based on selected feature.

A very basic variant management approach could be implemented with codeBeamer using based filtering: All artifacts that don't match the filter specific to the variant could be removed or hidden from the platform variant in the customer project.

Specifications only relevant in context of the customer project (e.g. requirements and tests related to a customer specific interface / API) are managed in the customer project directly.

Customer specific test sets are defined to support combining Test Cases defined on platform-level and in the customer project.

Completely Independent Variant

An independent variant is created by including all platform specifications in context of the customer project creating a new branch. Parts of the specifications not relevant in the customer project will not be included. Specifications can be adjusted and worked on independently and are isolated from changes in the platform. Changes in the platform can be incorporated into the customer project by merging in the changes in a controlled way. If the work is supposed to start from baselines of platform specifications, branching will be required.

Figure 4: Create Independent Customer-Specific Variant

Light-Weight Variant Creation

A light variant is created by sharing the platform specifications into the customer project and applying a filter at the same time that will exclude artifacts not relevant in the customer project.

Due to the fact that specifications are not branched all changes applied in the platform are apply to all sharing customer projects automatically.

The customer project team will have to work in the platform project to allocate customer requirements to platform requirements (codeBeamer will store the reference in the platform requirement).

Additionally the project team might want to apply extension relevant for their customer project to the platform.

This could be achieved by automatically adjusting the permissions when sharing the project.

Parts not relevant in the variant need to be filtered out in context of the Working-Set.

Figure 5: Shared Variant

Hybrid Approach

In the hybrid approach only specifications that need to evolve in the customer project independently are branched, all other specifications are shared.

Using this approach the customer project team will only require read-access to the platform project as all content that has to be modified in the customer project is branched.

Tracker that are include into the Customer Working-Set will not include parts not relevant in context of the variant. Trackers that are shared need to filter out irrellevant parts.

Figure 6: Hybrid Variant

Co-Evolution in a Customer Project

On the long run defining product functionality in a way that it can be re-used in multiple variants or customer projects will reduce cost of product development. On the other hand the added cost and time needed to re-usable functionally can be prohibitive when working in a customer project. Furthermore it can be more efficient for the team working with the customer to make the necessary adjustments instead of offloading all work to the team managing the platform. Co-evolution can be used to combine the benefits of both approaches:

• Customer specific functionality is defined in the customer project by adjusting platform artifacts as needed resulting in minimal effort and time spent on the adjustments.
• The team responsible for the customer project can make adjustments to the customer specific variant without the need to rely on the platform team.
• The added functionality is incorporated in the platform in a re-usable way later in collaboration with the team managing the platform.

This process can be implemented using a variant management tool or manually. The variant management tool will help to easily create a starting point for the co-evolution that is as close to the desired result to be created in the customer project as the variability of the platform permits. After creating the starting point for the co-evolution modification will be performed in the customer project.

Figure 8: Co-Evolution - Changes in Customer Project

Making functionality added in a customer project re-usable will require adjustments in many cases:

• Artifacts modified in the variant will have to be replaced with parameterized or conditionally included artifacts.
• Applicability and compatibility of added artifacts with other variants has to be confirmed.
• Conditions for inclusion of an artifact have to be defined.

Once the adjustments in the customer project have been refactored to be re-usable they can be merged into the platform using a merge request.

Figure 9: Co-Evolution - Bringing Back Changes into Platform

Interaction Over Time

Co-Evolution in Independent Variant

Figure 11: Time-Sequence of Co-Evolution in Independent Variant.

Hybrid Approach

Figure 12: Time-Sequence of Co-Evolution in a Hybrid-Variant.

Customer Input

Figure 14: Example Project Structure