Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Enforcing a Change Control Process in RQM

I'm working with a customer in the avionics domain (they need to comply with DO-178C).  A fundamental requirement for them is to be able to restrict changes to those that have been authorized and to be able to report on the change control record (work item in RTC terms) that authorized that a change to be made to an asset (and resulted in version N of an asset).

In RTC we can meet these requirements through a combination of preconditions:  requiring a work item to be able to deliver change sets and requiring that work items used to deliver change sets match a query.  I'm not seeing any way to automate the enforcement of this RQM ... even in 6.0.1.   In 5.x, we're manually linking a work item to the asset (e.g., test script) that needs to be changed...and we're requiring approvals in RQM, but it's up the approver to make sure that there is a work item that authorized the change. 

I was hoping that things would be different in 6.x, but even there, with global configurations and personal streams a possibility, I don't see anything helping to automate compliance.

0 votes



One answer

Permanent link
In RQM, it is possible to restrict changes to those that have been authorized by setting up the permissions in the project area  management UI.
All the modifications are tracked in the test artifact history, therefore you can report on who has made changes and when.
In addition, the integrated review and approval capability can be used to enforce that changes are reviewed and approved before test artifacts move to the state approved. A rule can be set so that only approved test cases can be executed.
We should look at the detailed use cases this customer would like to implement in RQM and see how best to map it with all the existing capabilities.

0 votes

Comments

Hi Christophe,

Thank you for your reply.  What permission(s) are you referring to? 

The Formal Review feature is being used.  It does not meet the requirements because  It's up to the approver to manually determine if a work item had been created that authorized the change. 

The pre-condition(s) that only allow execution of approved test cases/scripts are not related to this issue at all.  The gap is about controlling change; not about controlling execution.

We're not looking to simply report who made changes; we're looking for automation to assist in preventing changes from being delivered that have not been authorized (before the fact, not after the fact). Again, think RTC change sets and rules that can be applied that prevent delivery of unauthorized change.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 16
× 7

Question asked: Sep 14 '15, 10:25 a.m.

Question was seen: 2,939 times

Last updated: Sep 15 '15, 6:32 a.m.

Confirmation Cancel Confirm