Comparing concepts between ClearQuest and RTC
Introduction
There seems to be some confusion about the differences and similarities between Rational ClearQuest and Rational Team Concert. Some of this is due to changes in terminology, and some of this is due to the different usage models and capabilities of the products. This article seeks to clear up some of that confusion.
Basic Terminology
Let’s begin with some basic terminology and comparisons from ClearQuest. In ClearQuest you have the concept of a Record Type. These Record Types determine the different types of records that you can have in ClearQuest. They can be either stateless, or stateful records. Each Record Type has a number of Fields, and these Fields can be of different basic types (like enumerated, text, numeric, etc.). The Fields can be mandatory or optional, and they are often used to help categorize work. They can also be linked to each other. The Stateful Records are used to model process flow through a development organization. All of these various Record Types, and the enumerated data used to provided values for choice lists, are captured in what is commonly referred to as a ClearQuest Schema. These CQ Schemas can be exported and imported, but the format of the information is specialized and proprietary. As users interact with the system, they create CQ Records, which are instances of the type with data specific to some change request or work to be performed.
In Rational Team Concert (RTC) we have a Process Template which is used to dictate the structure and operation of RTC. In RTC we have Work Item Types, which are roughly equivalent to the Record Types in ClearQuest. A Work Item always has a state model associated with it, there is no concept of a stateless type. Jazz Work Item Types have Attributes, which are roughly equivalent to the Fields in ClearQuest. These are all identified in the process used by a project. When a project in RTC is started, it uses a Process Template to define the Work Item Types. It defines their Workflow and state models, their Attributes, and the various process operations that act on these Work Items (more on that in a little bit). This is all done with a “point and click” type of user interface. The selections and configurations done in this interface are captured in an XML representation of the process. This can then be used to create new Process Templates for other projects. As users interact with the system, they create Work Items, which are instances of the type with data specific to some change request or work to be performed.
Within ClearQuest, the Workflow can be characterized as a series of states. Individual records transition between these via a series of actions. In RTC, the concepts of states and actions are the same, with actions being used to transition between the various defined states. This is where RTC and ClearQuest begin to diverge a little bit. ClearQuest allows users to see the various stored records (data) as reports, query results, or diagrams fed by query results. These report formats may be native, delivered with the product, but are often customized and defined with Crystal Reports. RTC allows users to see the various stored work items (data) as reports, query results, or diagrams fed by query results. The report formats may be native, delivered with the product, but are customized and defined using BIRT. It also exposes this data in views called Plans. Plans show the Work Items (data) in a format that can be used for planning and monitoring progress of sprints or iterations. The individual Plans can be thought of as windows on the same data that just display it in a different way. The difference between reports and graphs is another example of looking at the same data, in different formats.
ClearQuest maintains a history of CQ Record transactions, and most customers will implement an Audit Trail capability with ClearQuest. Historical data and historical reports are built using data from the individual record histories. In RTC, Work Items have their own history, with comprehensive tracking of field and state changes. One additional thing that RTC will do is to populate it’s internal data warehouse over time, collecting and accumulating data from the Work Items. This data warehouse is used to provide data for all of the time-oriented reports and graphs shown in RTC. So, when looking at reports on data over a period of time (a burndown chart, for example), the data that you are seeing is coming from the RTC data warehouse. This pretty much covers the differences between RTC and ClearQuest from a basic functionality point of view.
Customizations
So what about customization and business logic in the process? When using ClearQuest, customers will implement more involved business logic by writing “Hook Code” in either Perl or Visual Basic, with Perl being the more popular choice with the most examples. This Hook Code is tied to particular events that occur to either a CQ Record, or one of it’s Fields. There is a rich set of API calls that will allow a schema designer the ability to perform various operations on those CQ Records and Fields. In RTC, the ability to modify the behavior of Work Items and Attributes is based on the built in security model (which is also customizable), and a series of common operations that customers will often perform. These are exposed as a series of operational behaviors and switches that the Process Template author can modify. For those things that are not already available in the tool, Process Template authors can write Extensions in any language, with Java being the popular choice with the most examples. There is a rich API and SDK that can be interacted with, and used to manipulate Work Items and their Attributes, as well as returning user guidance and error messages.
The next release of RTC contains additional functionality to address some of the gaps between RTC and ClearQuest, as well as providing additional capabilities. You can read more about these in the M4 New and Noteworthy and the M7 New and Noteworthy sections.
So how about a quick look at what you learned:
| ClearQuest Concept | Rough RTC Equivalent | What it does |
| CQ Schema | Process Template | It defines the process and how the tool exposes the process |
| Workflow | Workflow | A state model that defines the flow and transition of work products |
| CQ Record Type | Work item type | Defines an object type for holding data, with it’s own state model, defined fields, and presentation |
| CQ Record | Work item | An instance of the record type/work item type, with it’s own unique data |
| CQ Field | Attribute | One of the data entry fields, part of a record/work item |
| Hook Code | Extensions | Code associated with more customized implementation |
| CQ Database | Repository | Where information is stored |
| n/a | Plans | A different display or visualization of the current work item data, useful in project planning |
For more information
- Getting Started with Work Items – a tutorial that provides an introduction to RTC work items
- Work Item customization in RTC – a guide showing you many of the different ways that work items can be customized with RTC
- Work item editor presentations – a guide on how to modify how your work item data is presented to the RTC user
- Work Item attribute providers – one of the ways to customize Jazz choice lists.
- Jazz Administration Guide
- Jazz Deployment Guide
About the author
Daniel Toczala is the Technical lead of the Jazz Jumpstart team. He has worked with Rational Services in the past as a Senior Solutions Architect. He used his experience in helping a variety of customers in implementing organizational change to help build the concept of deployment patterns. He has done numerous presentations on how organizations can utilize Jazz technologies and Agile approaches to software development to improve the value that software development organizations deliver to their customers.
Dan travels the world helping IBM customer, but his home is in New Hartford, NY. He can be contacted at dtoczala@us.ibm.com.