This scenario describes a typical Rational® Change and DCM workflow for this methodology:
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.
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:
By default, when an object is received, any relationships from that object to other objects are reproduced in the receiving database. Moreover, any other appropriate relationships that exist in the receiving database, but are not in the transferred data, are deleted.
The following are 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.