Enter all change requests in a single database

The second methodology is to enter all change requests in one database. This database might 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 might 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 might be deferred and handed back to the main product management database. Later, the change request might 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, Rational Change Distributed checks change requests during the receive operation. In this example, Rational Change Distributed would find the change request in the assigned state that is being received in the development database. Rational Change Distributed checks for associated deferred tasks and reassign them. Details of automatically transitioned tasks are included in DCM email notifications.

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

The following are the main relationships in Rational Change:

Image showing the main relationships in Rational Change.

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 life cycle. Ensure that all associated tasks are in databases where the change request object exists, or disable 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 Rational Change Distributed is to skip receiving tasks that are modifiable in the receiving database.

Feedback