This 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.
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: System-wide settings
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: 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: 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: 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: 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: 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 220.127.116.11.
- 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: 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: 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: 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: 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.
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 18.104.22.168 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: http://www.eclipse.org/epf/downloads/openup/openup_downloads.php
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 22.214.171.124 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 126.96.36.199 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.
- For more information, see http://www.ibm.com/developerworks/rational/library/08/0212_miller/index.html
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community