Application lifecycle management with Rational ClearQuest Part 3. Administration and security requirements

from The Rational Edge: This overview of the concepts and design goals behind an out-of-the-box application lifecycle management (ALM) solution for IBM Rational ClearQuest illustrates the benefits of using ClearQuest and the ALM package as your change management (CM) solution. The third of a three-part series, this article discusses administration and security requirements, along with tips for getting started and integrating ClearQuest ALM into your environment. This content is part of the The Rational Edge.


Carolyn Pampino, Rational Solution Architect for GreenThreads, IBM

Author photoCarolyn Pampino is a Solution Architect on the Rational cross-product Green Threads team, and she currently focuses on Geographically Distributed Application Lifecycle Management. She contributed to the acquisition of IBM Rational Build Forge, where she served as a transition manager for product management. She has also contributed to the solutions and strategies related to integration with the Tivoli portfolio. Prior to joining IBM, Carolyn was the Director of Product Management, Development, and Competitive Intelligence at BroadVision, Inc, where she directed a geographically distributed team. Prior to BroadVision she was a Director of Development at Interleaf and was a member of the acquistion team that led to the acquisition of Interleaf by BroadVision. Carolyn received her degree with University Honors from Carnegie-Mellon University.

Robert Pierce, Advisory Information Developer, ClearTeam Group, EMC

Robert Pierce photoRob Pierce is an Advisory Information Developer for the Rational User Assistance group. He is currently documenting IBM Rational ClearQuest API Reference and Schema Developer role-based Help, as well as the Rational Team API. He is also a member of IBM and IBM Software Group Councils for Information Development (ID) focused on design and development of ID processes including working with support toward improvements in collaboration and consistency of information.

15 May 2008

Also available in Chinese Russian

illustrationThis three-part article presents an overview of the concepts and design goals of an out-of-the-box application lifecycle management (ALM) solution for IBM® Rational® ClearQuest®. In Part One, we illustrated the benefits of using ClearQuest and the ALM package as your change management (CM) solution, and presented design goals and many of the key concepts related to ALM in ClearQuest. In Part Two, we described the ClearQuest ALM solution and presented the concepts of the ALM role-based user experience, which applies both to change management in the context of IBM Rational product development, and to ClearQuest customer usage scenarios.

We conclude this series with Part Three, focusing on administration and security requirements, integration and coexistence considerations, and how to get started.

Administration and security

Now we'll cover the last of the key areas of functional capabilities in ClearQuest ALM: administration and security.

System-wide settings

The ALM solution comes with a set of system-wide settings, shown in Figure 1, that provide the power to modify the solution to fit your enterprise without impacting the underlying schema. These settings allow you to use your vocabulary for defining objects within the system; and, because they are system-wide, all users can share the same vocabulary.

figure 1

Figure 1: System-wide settings

Security policy

Security policies are defined by adding one or more ClearQuest groups to an ALM Security Policy record. Once set, project managers are free to create new projects and choose the security policy needed for that project. Administrators need not get involved. If a new policy is needed, creating one is simply a matter of defining a new security policy as shown in Figure 2.

figure 2

Figure 2: Creating a security policy

If everyone on the development team can view all records in the database, then a single security policy using the Everyone group can be created. This leaves the system open to everyone on the team. This is the easiest way to get started. However, as more security is needed, new security policies can be created to restrict viewing. For example, a group can be created to represent a third-party provider that is restricted to only those projects that they work on. All users from that third-party provider are added to that group. The security policy is created and the third-party group is selected. Projects for the third part are then assigned that security policy. Members of that group have no knowledge of any other records in the system, other than those with their security policy.

The Admin record is used to determine who can modify the system-wide settings. This gives you the freedom to empower trusted project leaders to modify the system settings (such as labels and category trees) as needed. Again, there are no changes to the underlying schema, but instead more freedom and flexibility for project leaders to customize the solution for your environment.


While we discussed categories in Part 1, it is important to note here that CategoryTypeLabels are available system-wide. Categories can be secured by a security policy and hence are available to or hidden from a particular user. This allows for re-use and consistent "classification" of categories across multiple projects.

Categories and Category Types allow you to model your classification system for projects. Categories can be hierarchical, as shown in Figure 3, enabling you to decompose large systems into smaller, more manageable units.

figure 3

Figure 3: Two category trees: One for Products, one for Services

To simplify Request and Task record creation, a Category can be given a "Current Project." When a new Request or Task is created, selecting the Category will automatically populate the project field. Figure 4 shows a Category record with the Current Project highlighted.

figure 4

Figure 4: A Category record with the Current Project highlighted


Types are used to identify the "nature" of the work. Types apply to Request, Task, and Activity, You set the types system-wide. Project teams then configure which types to use by creating a Work Configuration, as shown in Figure 5.

figure 5

Figure 5: The Type record

The Type record is very simple. Choose an ALMRecordType, then choose or create a TypeLabel. The Description is optional. Some examples of types include but are not limited to: Enhancement, Defect, New Feature, and so forth.


There are many instances where standardization across the enterprise is needed to help organize and govern projects, and rarely do we have tools to help enforce such consistency. With the introduction of Label records, you now have the opportunity to define a set of names that appear in the user interface, most often in the form of drop-down lists on records. Here we'll discuss each of the new label types and offers some suggestions for how you might use them.

Most Labels simply consist of a Name and a Description as shown in Figure 6.

figure 6

Figure 6: User interface for Label records

The following labels are set and shared across the database instance:

  • Category Type Label. Categories provide a powerful means of classifying projects, yet when defining such categories schemes you are likely to find yourself wishing you had more than one "tree" of categories. The Category Type Label allows you do just that. By defining more than one category type, you can now create hierarchies of categories belonging to one category type or another. An example is to define category types such as Solution, Product, SOA Service, Re-Usable Component, Business Unit, and so forth.
  • Phase and Iteration Labels. Many processes, including the IBM Rational Unified Process® (RUP®), recommend dividing projects into Phases, where each Phase can have one or more Iterations. Doing so helps to divide a project into more manageable units. For example, RUP suggests the following Phase labels: Inception, Elaboration, Construction, and Transition. An Iteration is a planned, time-boxed interval typically measured in weeks. Iterations focus the team on delivering incremental value to stakeholders in a predictable manner. By using Phase and Iteration labels you can ensure consistent adoption of terminology across your organization. For agile teams, a Phase can be treated like a milestone.
  • Release Label. Releases are used to identify the "version" of the software being developed. Some organizations standardize on release names or numbers. Use this field to identify a release label that will be used by others in the organization. For example, IBM has standardized on a four-digit release numbering scheme for all of our products, such as ClearQuest
  • Resolution Code Label. When units of work are completed, a resolution code is set to provide a history and context for the type of resolution. For example, not all work is completed in a project. Sometimes there are "duplicate" Requests, or a reported problem cannot be reproduced or works as designed. You have the opportunity to define a set of resolution codes to be used by your organization.
  • Role Label. Role labels help to ensure a consistent use of roles across the organization. Analyst, Architect, Project Manager, Developer, and Tester are examples of role labels.
  • Status Label. The status label is used to report the status or "health." This appears on the Project, Phase, and Iteration records. Some examples include: Healthy, Suspect, and Critical. Some organizations use color coding such as "Green" (for healthy), "Yellow" (for caution), and "Red" (for critical).
  • Work Type Label. Requests, Tasks, and Activities vary from organization by organization; therefore, each of these records has a drop-down list called Type. The names that appear on that list come from the Work Type record. You start by defining the Work Type Label. This is simply the name of the type, such as "Enhancement." You then use the Work Type to combine the record type with the label, such as the record type "Request," which has a type called "Enhancement."

Integrations and coexistence

Because ClearQuest ALM is provided as a set of packages (in addition to a schema), you can apply the packages to an existing ClearQuest database and begin making use of the records without impacting your users. Instead of attempting to migrate all of your data, start by bringing new project teams into the new model. This allows for a transition as teams complete current projects and start new ones. You can continue to run queries, create records, and run reports as you always have. All of your data can coexist in the same database.

Managing requirements with IBM Rational RequisitePro

Many organizations use IBM Rational Rational RequisitePro® to manage requirements and ClearQuest as the development team's CM system. An integration exists between RequisitePro and ClearQuest already. Using the ClearQuest Designer, apply the RequisitePro package to your schema, if this hasn't been done already. Next decide which record types to enable as shown in Figure 7.

figure 7

Figure 7: Applying the RequisitePro package to your ClearQuest schema

This choice of what record types to enable depends on how you plan to manage your requirements. Many times a single requirement could apply to multiple projects, in which case the recommendation is to enable the ALMRequest record. Alternatively, the ALMTask or ALMActivity can be enabled. A requirements tab is added to the enabled record, which allows you to associate RequisitePro requirements. The ALMRequests will contain the project "found-in" context and a reference to the requirement(s). ALMTasks will fulfill the requests in the context of one or more projects.

What about UCM integration?

The ALMActivity is the same as the Unified Change Management (UCM) activity. The difference with the ALM solution is that the definition of "activity" has been expanded to include a unit of work for any team member. This means that all ALMActivity types (see Figure 8) are UCM-enabled.

figure 8

Figure 8: ALM Activities are UCM-enabled.

Note the Unified Change Management tab on the ALMActivity record, shown above. This is an optional setting for teams that are using UCM.

Rational Team Concert

IBM Rational Team Concert Express is available for small, agile teams.1 As existing Rational customers deploy and adopt Rational Team Concert, questions of interoperability arise. There are IBM Rational ClearCase® and ClearQuest connectors available with Rational Team Concert.

The points of alignment between these products is as follows:

  • Work. The ClearQuest connectors facilitate the ability to create a record in one database and have it appear in the other. This allows for modifications to the record by users in either system. The options are as follows:
  • Work-item and ALMActivity share the same attributes to provide easier interoperability (see Figure 9).

figure 9

Figure 9: Interoperability between ALMActivity and Rational Team Concert work-items

  • Rational Team Concert work-item (which has child work-items, or of type Task) and ALMTask (see Figure 10).

figure 10

Figure 10: Interoperability among ALMTask Rational Team Concert hierarchical work-items, or work-items of type Task

  • ALM Requests can be viewed in a couple of ways. On one hand you might align a Request of type Defect to a work-item of type Defect. On the other hand, you might treat Requests more like requirements and determine that there is not a direct relationship yet.
  • Project -- both Rational Team Concert and ClearQuest have projects. This requires a manual alignment of names.
  • Category -- both Rational Team Concert and ClearQuest have category trees. This requires a manual alignment.
  • Role -- both Rational Team Concert and ClearQuest have Role definitions. This requires a manual alignment.

Getting Started

Having now covered the ClearQuest ALM solution's functional capabilities and its relation to some other Rational products, we'll lastly offer some thoughts on bringing ClearQuest ALM into your organization.

ClearQuest schema and packages

ClearQuest provides a new schema, called ALM, which you can use to get started managing your teams.

The ALM records are also provided in a set of two packages, called ALMProject and ALMWork. You can apply these packages to an existing schema without impacting your current teams or record types. All records are prefaced with "ALM" to help distinguish them from other records in your current schema. Additionally, guidance is provided to enable you to safely modify the packages without locking yourself out from future upgrades.

OpenUP sample database

A sample database is provided to help get you started with the new schema. It's highly recommended that you start with this sample database to familiarize yourself with the new records and their relationships.

This sample database, and set of importable files, is based on the OpenUP (Open Unified Process), which is an exemplary process in the Eclipse Process Framework project. OpenUP is a customization of RUP scaled for agile teams. OpenUP downloads are available from the following URL:

The "published" version is viewable in a browser, with all content stored on the local hard drive.

In this sample database a set of labels, work types, work configurations, and queries are already provided. Additionally, a sample project is provided. OpenUP processes are mapped to the ALM Task and Activity records to illustrate how to bring process into managing projects using ClearQuest.

We hope to provide a tour of the OpenUP sample database and project in a future article in The Rational Edge.


The new ALM schema in Rational ClearQuest provides an out-of-the-box set of building blocks for project teams to customize according to their own cultures and processes. This frees ClearQuest administrators from having to edit the schema, while empowering project leads to customize the system to suit their needs.

This new solution drastically decreases the total cost of ownership for ALM tools and processes. The requirements gathering process is streamlined because you no longer need to get all project teams to agree on record types and state transitions. Instead, you can let each team define their own process and work types.

Schema design is also streamlined. Again, reducing the complexity of individual record types and state transitions reduces the time required to design the schema. Instead your time can be dedicated to designing security policies, category trees, and the system labels. You might also choose to add a tab with additional fields to the forms that are provided to capture additional information.

Implementation effort is also reduced, as the forms and hook code are provided out-of-the-box. Your implementation time is spent adjusting the out-of-the-box experience instead of having to start from the ground up.

The need for custom training is also reduced. The online help, tutorial, sample database, and IBM developerWorks articles such as this one provide a baseline of training that you can use.

With the reduced need to define record types and transitions, and the out-of-the-box building blocks included in the solution, teams can more easily self-organize around projects, which can be secured using security context. Role definitions can be used to determine what action each user is allowed to perform on a project.

ClearQuest ALM can also greatly improve your ability to govern development projects. By managing the work assignments for all users on the team you can now run queries, reports, and charts that provide much more insight into the health of your project than previously possible. For the first time, your internal process guidance (such as your custom version of RUP) can become "actionable" by instantiating the core concepts into your Role, Type, and Work Configurations.

The ALM schema and packages provide a scalable CM workflow solution that captures the best practices of software development process design. It provides a solid foundation for managing development projects, with flexibility to customize each project built into the schema. Reduce your cost of ownership and empower your project teams to work according to their needs by adopting the ClearQuest ALM solution.


Special thanks to the many who have contributed their time and talent to the creation and review of this article. In alphabetical order: Kenneth Giffels, Robert W. Myers, Michael J. Saylor, and Rick Weaver.


  1. For more information, see



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Application lifecycle management with Rational ClearQuest Part 3. Administration and security requirements