Considerations in state model design

Dead ends

You must make sure there are no states in the model to which a change request can be transitioned and then overlooked. For example, if the model has a Postponed state, and no one is assigned to process records in this state, some change requests might never be noticed or fixed.

The causes of this problem can be subtle. Three engineers might be assigned to handle change requests in an Open state, where the value in the component field is red, green, and blue, respectively. Change requests whose component field value is yellow or blank might never be noticed.

Number of states

You must consider the trade-offs between a model that has a fewer states with more development activities for each and a model that has many states with fewer development activities. For example, if a verification activity occurs at several points in the life cycle of a change request, you might want to have one verification state instead of incorporating verification activities in the other states. Grouping these activities into one state makes it easier to ensure that verification is handled properly. But creating many states makes the model unwieldy and harder to maintain.

Duplicate records

The Duplicate action provides a means to mark one record in a set of duplicate records as the active record and mark the others as duplicates; records marked as duplicates cannot be modified. This action ensures that all work on this change request is tracked by one record. This action uses built-in fields; it can be added to a schema by adding the Duplicate Dependent and Duplicate Base controls to a form and by creating Duplicate and Unduplicate actions. The Unduplicate action returns the record to its state before it was marked as a duplicate.

Predefined schemas

A variety of predefined schemas that incorporate specific features or configurations are available. You can use them as a starting point for developing a schema, but you must compare the features of the predefined schema with your requirements carefully.

Some key points to consider about these predefined schemas:

• Use the Blank schema to design a new schema.
• The Common schema defines a single Defect record type with many features that you might (or might not) need.
• The Defect Tracking schema demonstrates the record cross-referencing capabilities within the database and the navigational features of Rational® ClearQuest® clients. It is based on the Common schema and adds a Customer stateless record type with a Reference_List field from the Defect record type.
• The Analyst, Development, and Test Studio schemas are based on the Common schema and facilitate integration with the corresponding DevOps Suite products.
• The UnifiedChangeManagement schema is based on the Common schema extended for theDevOps Code ClearCase® integration with UCM.
• The EnterpriseStudio schema is based on the Common schema and facilitates integration with all the DevOps Suite integrations and UCM.

Parallel development

Designing a schema to support parallel development of multiple products (or product variants) that share common artifacts is a challenge. The design must anticipate and accommodate such situations as how to capture and handle information when a reported defect is traced to shared artifacts that require fixes to multiple products and how to track the current state of the defect when multiple builds (on potentially different schedules) are required.

Using a single record to track these different efforts is not an effective approach.

An alternative approach is to submit multiple records for each product affected, which allows the status of each activity to be tracked independently. If you use the Save Default Values mechanism on the first record entered and use Load on subsequent records, you can avoid duplicating the data entry on each copy. (This capability is not available for the Rational ClearQuest Web client.) The drawback is that each record is isolated from the others; effort can be wasted if the work on the other related issues is not coordinated.

A more effective approach is to use a hierarchical structure, in which the parent record characterizes the issue, and the child records are used to track the issue for each product, variant, or version. The parent record can be a different type from the child records, or it can be the same. Some schemas use the same record type for the parent and child records so that all the information can be contained in the child (which reduces navigation between parent and child). Other schemas use a simple child record type to implement a kind of reminder to address the same issue for the other affected products, variants, or versions and to track their status.