Understanding the functions of the Rational ClearQuest schema developer

This topic provides an overview of the tasks typically performed by a schema developer.

As a schema developer, you are typically responsible for designing and modifying process models by defining, implementing, testing, and managing schemas. You might also enable e-mail access, and create or modify public queries, charts and reports.

These are common tasks for the schema developer:
These common tasks are described in this topic. The descriptions include pointers to information on each function.

Designing the process model of the change management system

Describing all of the work required to design and implement a change request management system is beyond the scope of this help system. But you must invest the time to create a comprehensive implementation plan. A significant effort is typically required to analyze existing processes (because they are rarely documented) and to achieve consensus on how they ought to work.

To design and implement a change request management process:

  1. Identify the scope of the process.
  2. Determine the roles of the different types of users.
  3. Construct the change management process model.
  4. Obtain agreement about the model from users and management.
  5. Train users and deploy the system.
  6. Enforce the change management process.

A team might be jointly responsible for many of these tasks, but as the schema developer you must ensure that none are overlooked.

Creating and managing schema repositories and connections

Use the Maintenance Tool to create and manage schema repositories.

When you create a schema repository, you also create a connection (or database set) that keeps track of all of the databases associated with schemas in that schema repository. You then use the Maintenance Tool to manage these connections.

You also use the Designer to create a user database and associate it with a predefined schema.

For more information, see Manage databases.

Developing the schema

Document the process model or models that the schema must enforce. The documentation might include this information:

When the requirements are known, create or modify a schema to build the process model.

Several predefined schemas are available to help with this task.

Table 1. Predefined schemas
Schema Description
ALM The Application Lifecycle Management (ALM) schema provides fields and rules to help coordinate software development activities, and supports the lifecycle management of assets and their relationships.
Blank Contains only system fields. A minimum configuration base for building schemas.
Common A base-level configuration with the most commonly used schema elements.
DefectTracking A schema with features for defect-tracking processes.
Enterprise A schema with fields and rules that allow Rational ClearQuest to be used with IBM Rational Suite Enterprise. Contains fields and hooks that work with all IBM Rational products.
UnifiedChangeManagement A schema with fields and rules that allow Rational ClearQuest to be used with Rational UCM.

To create a schema that models your process, you have several options:

Upgrading user databases

When you create or modify a schema, use the Designer to create or upgrade user databases to work with the latest version of the schema.

For more information, see Manage user accounts.

Enabling e-mail notification

You can set up the Rational E-Mail Reader to allow users to submit and modify change requests by e-mail instead of using the Rational ClearQuest client.

To do this, you set up at least one dedicated e-mail account. Users can send messages to this account when they want to submit or modify a change request. The e-mail message must follow a set format so that the data in it can be interpreted by the Rational E-Mail Reader, which runs as a Windows Service on the database server. To assist users in submitting e-mail messages that can be parsed and processed by the Rational E-Mail Reader, you can create and distribute template e-mail messages that follow the correct format.

You can also create rules that notify Rational ClearQuest users by e-mail when a specified event occurs.

To do this, you apply the E-mail package to all schemas that you want to be able to accept information through e-mail. This package creates a stateless record type called Email_Rule. You can then create a set of rules that trigger an e-mail notification when a specific event occurs, such as the transition of a change request to a new state.

For more information, see Rational ClearQuest e-mail.

Importing and exporting data

You can import and export data from other data sources by using the Import and Export wizards in either the Rational ClearQuest Client or the Rational ClearQuest Client for Eclipse.

For more information, see Overview of importing and exporting data.

Creating public queries, charts, and reports

You can create and modify queries, charts, and reports and store them in the Public Queries folder to be available to all users. Alternatively, you can delegate these tasks to other users such as project managers. For information about required user privileges to creating public queries, charts, or reports, see User privileges.

To create reports, you must acquire a license for a reporting tool, such as the Rational SoDA software or Crystal Reports software from Business Objects, Inc, or use the open-source BIRT Report Designer and runtime engine that are included with the Rational ClearQuest Client. For more information about reporting, see Planning and configuring the reporting environment.

Setting security controls

You can design and implement secure access to functions and data.
  • User authentication
  • User authorization
    Authorization is based on user privileges and other security features.
  • User profiles
    A user profile defines the databases a user can access, the user privilege setting, and the user groups associated with a user.
  • A security model for record types

    One of the most powerful capabilities related to managing user accounts is the ability to set security controls on records so that you can control the information that is available to individual user groups. For example, you might want to allow customers to submit and view change requests, without being able to see sensitive information about change requests submitted by other customers or by members of your development team.

    To set up this type of security, you can make records visible only to specific user groups. You can also restrict access to fields on a record form tab to specific user groups.

    You set security controls on records by creating a security context field in the record type, and then assigning user groups permission to see records that have a certain value in this field.

For more information about security, see Creating a security model


Feedback