Change Request Lifecycle
One important concept to understand, before we dig deeper into the system, is that of the change request lifecycle. The first step in understanding this concept is to know the difference between an action and a state. An action is a step you take to resolve a request (open, close, assign, postpone, reject, validate, or duplicate). A state is a definition of where the change request is within the lifecycle (opened, closed, assigned, postponed, rejected, resolved, submitted, or duplicated).
Actions and states represent all of the various lifecycle variables your change requests can encounter within your process.
The standard ClearQuest training materials contain a great model, shown in Figure 4-2, that outlines each step of a basic software defect.
Figure 4-2 Life of a software defect
Let's introduce some additional terminology that you may find important as you navigate through ClearQuest.
In a relational database, you're probably familiar with the use of tables to organize your data. In ClearQuest, these tables are called record types. For example, defects and enhancements are two record types. There are two different kinds of record types: state-based and stateless. State-based records have a state transition model to represent their lifecycles in the defect- and change-tracking process; a stateless record type does not have these transitions. Once a user submits a new record of a stateless record type, it will stay in the database forever until it is explicitly removed. In other words, the stateless record type is suitable for records that do not require lifecycle tracking. The relationship between different record types is known as referencing.