Impossible to relate a Change Package to an Item when the Change Package is already created

[fantony-2]

In Configuration Management of Integrity, it is impossible to relate a Change Package to an Item (like a defect for example) when the Change Package is already created. It should be possible due to the fact that sometimes, Defects can be created after the Change Package is created. The workaround proposed by the support that is to create a new Change Package and move the entries is not a powerful way of work and time consuming.

In software developement process (for automotive or aircraft), Defects are often created after the Change Packages are created and it is very important to have the functionnality to relate a defect with an already created Change Package :

- to keep the traceability between source code files and defects

- to keep a agile way of work due to the fact that the amount of defects and Change Packages is very important

[AmartyaMallick]

Hi,

For better clarity, could you please share with us a bit more on this?

Scenario:

1. A User has created Defect-A in the system.
2. Against Defect-A, Change Package CP1 is created.
3. Changes need to be made in “member Prog1“ to resolve Defect-A.
4. The “member Prog1“ is checked out against CP1 for the changes to be tracked, reviewed, approved and then committed.
5. In the meantime, another or same user creates a Defect-B.
6. The same “member Prog1“ is required to change in order to fix Defect-B
7. Since Prog1 is linked to CP1 which is tied to Defect-A, the subsequent defect Defect-B needs to be pended till CP1 is fully complete

Does the above scenario describe the problem that you are trying to solve?

Regards

Marty

[fantony-2]

Hi Marty,

The scenario you described is not about the topic I would solve.

Please, find hereunder a screenshot of my CP :

In the list above, you can see that I have CPs with related Item and CPs without related Item.

So, our problem is if I created the CP 1222854:1 without a related Item (Defect), it is currently impossible to relate an Item (Defect) with the already created CP 1222854:1

Then, in this case, it is mandatory for the user to create a new CP against the Item (Defect) and move the entries from the old CP to the new one.

When a user creates a lot of CPs, it is very convenient to create new CPs and move entries. PTC Integrity should allow to attach Items to CPs that was already created…

Is it more clarified for you?

Regards,

Frédéric.

[fantony-2]

Moreover, a Change Package should be able to be bound to several Items (Defects) and not only one (mandatory too for us). I'm very surprised to be the only customer to request this kind of requirement...

[AmartyaMallick]

Hi,

This is a very interesting use case. This gives us an insight into what you would expect from the Source application. Further interest in this use case from other customers will help us understand the finer aspects to get a good definition of the value statement.

Regards

Marty

[LLawton]

I think I understand the use case and in fact, being able to relate the same change to multiple CPs would help us a lot too.

I do have a question and a suggestion:

- Question: Why do you have CPs without items, is it because you want it that way? Otherwise, it is perfectly possible to prevent that and force a CP to always be against an item of a given type.

- Suggestion: could Source Links or Source Traces be a solution? In our system, we use Source Links to link code to items that don't allow CPs. We don't use Source Traces because they don't keep a version-specific link, unfortunately.

I think PTC should seriously consider asking the community about such use cases and our needs.

[fantony-2]

Why do you have CPs without items, is it because you want it that way? When our teams develop a software (for mock-up for example), we do not have to use the change process (Defect, Change Request). In this case, CPs are created without related items. But from a specific milestone of our development process, it is mandatory for us (airworthness norms DO178...) to modify a source code file according to a Defect or a Change Request. In this case, it is mandatory for us to relate a Defect Item or a Change Request Item to one or Several CPs and to related one CP to one or several Defects/Change Requests.

[khoppe]

@fantony-2 
The Approach having multiple Relations between Items and CP's does have some Risk.
I postulate that you need to have Items and CPs open while working. See this Example to identify the Risk.

You have Item1 of Project-a and Item2 of Project-b.  AND you have CP1 and CP2, connected to Item1 and Item2.

This can lead to the Situation that a Change, planned for Project-b only, but documented in CP2, initially created for Item2 only, will get active as Change for Project-a as well cause of the Relation from CP2 to Item1.

This Risk is comparable to the Approach to create a Normal Share from a Development Area into a Customer Project, instead of using a Built Share.