Enter all change requests in a single database

The second methodology is to enter all change requests in one database. This database could be a main product management database from which a company controls changes to a number of applications.

This scenario describes a typical Rational Change and DCM workflow for this methodology:

  1. A change request is entered in the main product management database.
  2. The change request is verified, rejected, or marked as duplicate in that database.
  3. The change request is assigned to a product development team leader, and then it is handed over to the corresponding development database.
  4. All associated tasks are entered and assigned in one development database.
  5. Upon completion of all tasks, the product development team leader resolves the change request and hands it over to the main product management database.
  6. A concluder in the main product management database either concludes the change request, or sends it back for rework in the development database.

    Replication of tasks from the development databases back to the main product management database can also be required. This operation allows reports to be created and keeps product managers informed about the progress of tasks. In other cases, details of completed tasks might be sufficient, and the transfer sets could exclude incomplete tasks. In still other cases, it can be unnecessary to transfer any tasks from the development databases to the main product management database.

If selective replication is needed, a change request query is typically based on product name or product subsystem (and possibly the status of the change request). In such cases, transfer sets must not exclude imported objects — otherwise, handover of the imported objects back to the main product management database never takes place.

Special cases

If you use Sample Methodology 2, special processing is sometimes required.

When Rational Change is used to defer an assigned change request, any associated assigned tasks are also deferred. When the change request is reassigned, any associated deferred tasks are once again assigned.

In this scenario, a change request that is assigned and being worked on in a development database could be deferred by a team leader and handed back to the main product management database. Later, the change request could be reassigned. However, the associated tasks might not exist in the main product management database. Even if they did, they could not be modified there.

To handle this situation, DCS checks change requests during the receive operation. In this example, DCS would find the change request in the assigned state that is being received in the development database. DCS would check for any associated deferred tasks and reassign them. Details of such automatically transitioned tasks are included in DCM email notifications.

The default DCS model parameters are adequate in most cases, provided you use one or both of these implementations:

As shown in the figure, the main relationships in Rational Change are:

Rational Change main relationships, change request to task and task to object

Due to the object relationships shown in the figure, a problem occurs when only some tasks are replicated back to the main product management database: If a change request is replicated to the development database, the change request is associated only with some, but not all, of the appropriate tasks. By default, during a DCM receive operation, the other tasks are disassociated from the change request.

To avoid this problem, use the correct DCM workflow associated with the Rational Change lifecycle. Make sure that all the associated tasks are in the databases where the change request object exists, or disable the image handling when change requests are received. This operation removes all the specified implementation restrictions; however, task deletions or the removal of relationships are not replicated.

Note: By default, this problem does not exist with tasks and their associated objects. The default behavior of DCS is to skip the receive of tasks that are modifiable in the receiving database. This behavior can be modified; however, read DCS model parameters before doing so.

Feedback