Best practices for reuse and sync?

Brian McCormack

Hi all,
There are a few older threads on this topic, but I'd like to get some recent user feedback.

We're starting a new project (Project based on an existing project (Project A). The projects have a high degree of commonality, and have multiple relationship levels within each project (system requirement -> subsystem requirement - > test case etc.). The projects are not sequential releases, and hence need to be developed in parallel. Looking to use reuse and sync for branching and merging.

Is it better to reuse and sync the entire Project A, then select which items are relevant for Project B, or is it better to select the impacted items in Project A first and only reuse these?

Thanks,
Brian

------------------------------
Brian McCormack
------------------------------

Alessandro Valli

Hi Brian,

there as several approaches for this.

Let's say you have several variants of a product, the number of items in common is high and development of variants is in parallel. In such a case, I suggest you to think about having a project for all variants (150% project, just to use a name widely used). This approached is based on the approach for Software Product Lines and the project will contain all generic and specific items of the product line. I do not want to make it too long, but in such a case you avoid to duplicate (sync/reuse too much). You look on the web for feature based development too

On the other hand, having several project with items in common you have to maintain them in sync. The simple reuse (no sync, no relationship between source and target) is generating no "association" (I do not want to use the word relationship) between items that should be "the same". You can sync, but you have to take care of maintaining the sync, as there is no automatic way to do this in Jama. In addition the sync functionality is simply the sharing of the global ID of a set of items. There is no direction, thus you need conventions which is your reference according to which you sync the other items. A high number of items in sync is giving also performance issues (my experience). You can reuse items with a relationship between source and target. Here you have the directionality, but are missing the possibility put items in-sync that are out-of-sync.

At the end of the day my suggestion is,

• if you are going to have plenty of variants, then go for a 150% approach (Pros: no sync, less administrative efforts; Cons: you need some method to "describe" your items as generic or specific -> see feature based development, your project could reach a high number of items) -> Product Line
• if you have not that many projects, the number of items in common is not too high and the items in common shall have the latest version in each project, then you can go for sync (Pros: easy to get the items in-sync; Cons: you need some processes/agreements to decide which is your source to be used to put the other in-sync, difficult for hot-fixes in single projects) -> project with a platform in common
• if you have an set of items in common that are not changing that often and it could be that you are going to have also several versions in use, then you can set a source project with the items in common and then reuse them (with relationship) in the desired projects (Pros: you manage separately your items in common, you have full traceability; Cons: you need processes/agreements, difficult to merge back to the origin local changes in your project) -> managed cloning

A lot of words, I hope it helps ...

------------------------------
Alessandro
Systems Engineer
SICK AG
------------------------------
-------------------------------------------
Original Message:
Sent: 11-24-2022 02:35
From: Brian McCormack
Subject: Best practices for reuse and sync?

Hi all,
There are a few older threads on this topic, but I'd like to get some recent user feedback.

We're starting a new project (Project based on an existing project (Project A). The projects have a high degree of commonality, and have multiple relationship levels within each project (system requirement -> subsystem requirement - > test case etc.). The projects are not sequential releases, and hence need to be developed in parallel. Looking to use reuse and sync for branching and merging.

Is it better to reuse and sync the entire Project A, then select which items are relevant for Project B, or is it better to select the impacted items in Project A first and only reuse these?

Thanks,
Brian

------------------------------
Brian McCormack
------------------------------

Brian McCormack

Hi Alessandro,
Thanks for the detailed feedback (and for the excellent SICK sensors we use in our products!).

I'm leaning towards your "project with a platform in common" approach, syncing the entire source project down to a test case level, and then filtering / tagging in the destination project to identify the relevant items. My primary concern is that it's difficult to know upfront all of the items which will be impacted in the destination project, and in practice they are likely to be identified over several iterations. It looks cleaner just to sync the entire project and work on identifying the relevant subset in the destination project, rather than attempt to sync them item-by-item as the scope if clarified.

FYI, we're had negative experiences in the past with cloned/un-linked projects, mainly with propagating unexpected changes between projects. I completely agreed that you need processes to manage change propagation (regardless of how it's performed), but reuse and sync acts as a good comparison tool even just to at highlight differences.

Thanks,
Brian

------------------------------
Brian McCormack
------------------------------
-------------------------------------------
Original Message:
Sent: 11-24-2022 04:50
From: Alessandro Valli
Subject: Best practices for reuse and sync?

Hi Brian,

there as several approaches for this.

Let's say you have several variants of a product, the number of items in common is high and development of variants is in parallel. In such a case, I suggest you to think about having a project for all variants (150% project, just to use a name widely used). This approached is based on the approach for Software Product Lines and the project will contain all generic and specific items of the product line. I do not want to make it too long, but in such a case you avoid to duplicate (sync/reuse too much). You look on the web for feature based development too

On the other hand, having several project with items in common you have to maintain them in sync. The simple reuse (no sync, no relationship between source and target) is generating no "association" (I do not want to use the word relationship) between items that should be "the same". You can sync, but you have to take care of maintaining the sync, as there is no automatic way to do this in Jama. In addition the sync functionality is simply the sharing of the global ID of a set of items. There is no direction, thus you need conventions which is your reference according to which you sync the other items. A high number of items in sync is giving also performance issues (my experience). You can reuse items with a relationship between source and target. Here you have the directionality, but are missing the possibility put items in-sync that are out-of-sync.

At the end of the day my suggestion is,

• if you are going to have plenty of variants, then go for a 150% approach (Pros: no sync, less administrative efforts; Cons: you need some method to "describe" your items as generic or specific -> see feature based development, your project could reach a high number of items) -> Product Line
• if you have not that many projects, the number of items in common is not too high and the items in common shall have the latest version in each project, then you can go for sync (Pros: easy to get the items in-sync; Cons: you need some processes/agreements to decide which is your source to be used to put the other in-sync, difficult for hot-fixes in single projects) -> project with a platform in common
• if you have an set of items in common that are not changing that often and it could be that you are going to have also several versions in use, then you can set a source project with the items in common and then reuse them (with relationship) in the desired projects (Pros: you manage separately your items in common, you have full traceability; Cons: you need processes/agreements, difficult to merge back to the origin local changes in your project) -> managed cloning

A lot of words, I hope it helps ...

------------------------------
Alessandro
Systems Engineer
SICK AG
------------------------------

Original Message:
Sent: 11-24-2022 02:35
From: Brian McCormack
Subject: Best practices for reuse and sync?

Hi all,
There are a few older threads on this topic, but I'd like to get some recent user feedback.

We're starting a new project (Project based on an existing project (Project A). The projects have a high degree of commonality, and have multiple relationship levels within each project (system requirement -> subsystem requirement - > test case etc.). The projects are not sequential releases, and hence need to be developed in parallel. Looking to use reuse and sync for branching and merging.

Is it better to reuse and sync the entire Project A, then select which items are relevant for Project B, or is it better to select the impacted items in Project A first and only reuse these?

Thanks,
Brian

------------------------------
Brian McCormack
------------------------------