ALM With CQ 7.1 Part 1

8/8/2019 ALM With CQ 7.1 Part 1

1/11

Application lifecycle management with ClearQuest

7.1.0.0: Part I

Carolyn Pampino, Rational Solution Architect for GreenThreads, IBM

Robert Pierce, Advisory Information Developer, ClearTeam Group, IBM

Summary: 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 first of a

two-part series, this article presents both the concepts and design goals of ALM in ClearQuest. This content is

part of the The Rational Edge.

Date: 15 Mar 2008

Level: Introductory

Activity: 1744 views

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. Here in Part

One, we will illustrate the benefits of using Rational ClearQuest

and the ALM package as your change management (CM) solution

and present both the concepts and design goals of ALM in

ClearQuest.

In parts 2 and 3, we'll describe in detail the ClearQuest ALM

solution and present the concepts of the ALM role-based userexperience, which applies both to change management in the context of IBM Rational product development,

and to ClearQuest customer usage scenarios.

Managing change through the application lifecycle

Managing complexity in terms of governance, security, ownership, and globally distributed development

(GDD), as well as ALM, creates a need for managing change. Using a CM software tool, such as ClearQuest,

and defining processes around that tool can provide great benefits by helping to link and coordinate different

groups or teams within the development organization, regardless of whether they are all in one building, or

geographically distributed all over the world.

As illustrated in Figure 1, the fundamental premise of ALM is to facilitate processes for developing software

that span multiple team roles during the project, while managing all of the content that is produced by each

role along the way. Team members rely on five pillars of capability to support their development effort. They

need to 1) collaborate; 2) ensure the results of their work are traceable to the originating request; 3) automate

non-creative, repetitive tasks; 4) seek strategies to continuously improve; and 5) if teams are distributed they

need to ensure a close connection to the software delivery chain.

ication lifecycle management with ClearQuest 7.1.0.0: Part I http://www.ibm.com/developerworks/rational/library/edge/08/m

1 12/1/2009


2/11


3/11

with sufficient quality before agreeing to deliver the solution. The challenge for software development teams

is not in creating a single artifact (source code, requirement, or test case) but rather in understanding the

relationships between those artifacts.

ClearQuest application lifecycle management

Rational ClearQuest 7.1.0.0 includes an out-of-the-box ALM solution that provides support for managing

many of the challenges presented by GDD and ALM. The ALM package provides support for a streamlined,

agile application development process that is both role-based and process-driven, as illustrated in Figure 3.Projects define a context for completing work and can be secured by setting security policies and defining

roles. Work can be assigned to team members who are either co-located or distributed. That work is traceable

to the original request, and traceable to the project that implemented the request.

Figure 3: ClearQuest ALM supports role-based development processes.

Overview and design goals

The ALM schema provides a set of records with relationships that help teams manage software development

projects. The ALM schema (and packages) is designed and built to provide the benefits listed here.


1 12/1/2009


4/11

Useful to 100% of new and existing ClearQuest customers

Provide a solution that is scalable from small teams to enterprise-wide organizations

Support globally distributed development teams. Supports, but does not require multisite and UCM

Delivered with ClearQuest v7.1 as a set of packages and a schema. The ALM Packages can be applied

to ClearQuest 7.0.1.

Reduce customer cost-of-ownership and improve ROI

Provide at least 70% of functionality out-of-the box

Reduce time to deployment by at least 50%

Reduce the amount of administrative changes needed to support enterprise usersEmpower project managers and team leads to configure projects without impacting the schema

Provide fundamental "building blocks" to get started

Provide an out-of-box experience that captures ALM "best practices" which can be used as is, or

extended and applied to existing ClearQuest implementations

Provide a secure project context with role-based "allowed actions"

Facilitate team coordination of work throughout the software development lifecycle

Simplify the ability to support regulatory compliance initiatives, and maintain audit trails

Provide an out-of-box sample database demonstrating support for the OpenUP exemplary process from

the Eclipse Process Framework

The ALM schema's principle role is to help teams manage the work involved in delivering software projects.The ALM schema also provides useful building blocks and frameworks that facilitate custom configurations

to fit into every enterprise.

Core concepts

There are three essential concepts to understand when working with the ALM schema in ClearQuest:

Projects provide the context for managing work created by the members of the team. Users are granted

access to projects through Security policies, and their actions are defined by theirRole.

Managing work is enabled in the form ofRequests, Tasks, and Activities. The definition of activities

and tasks is driven by process definitions which can change from project team to project team.System-wide settings can be defined for projects and managing work. These settings allow for re-use

and consistent "classification" across multiple projects, and can adapt to the enterprise. These typically

involve a one-time set up, or minor changes as the teams grow and evolve with their use of the system.

(CQ Administrators would start here.)

This rest of this article describes the first of these fundamental concepts, how Projects provide a role-based

context for work. The second and third concepts are covered in Part Two.

Projects provide a role-based context for work

All work in the ALM schema is organized by a Project. The Project provides the context, access control, and

role-based security model for your work. The Project Management Body of Knowledge (PMBOK) defines

"Project" as a temporary endeavor undertaken to create a unique product, service, or result. In an ALM

system, it is the context within which work is done, and provides traceability for the work completed during

the software project 's lifecycle. The Figure 4 illustrates the architecture of an ALM Project, including the

objects that comprise a Project definition, system-wide settings, and existing ClearQuest User and Group

administration.


1 12/1/2009


5/11

Figure 4: ClearQuest ALM: Conceptual overview of projects. All work in the ALM schema is

organized by a Project. The Project provides both the context and role-based security model for your

work.

The rest of this section describes the records that are used to define the project.

Project security

Security is an important aspect of all project-based work. In the ALM Schema project security is defined by

who has access to the project, and what they can do. The Figure 5 illustrates the record types involved in

defining the security policy and roles for a project

.

Figure 5: Security Polices provide access, and Roles define Allowed Actions.

The steps for establishing security as shown in Figure 5 can be described as follows:

Create Users and Groups. Existing ClearQuest deployments already have users and groups established.

Use these group definitions for defining the security policy. For new ClearQuest deployments consult

the ClearQuest documentation for creating users and groups.

1.


1 12/1/2009


6/11

Create Security Policies. The use of security policies is a fundamental concept in the design. A security

policy is created to define which users have access to the project. It is simply a matter of adding one or

more ClearQuest groups to a security policy record. For some organizations, access control to projects

may not be a significant issue. If this is the case, you can simply create one security policy and add all

ClearQuest groups to it. This security policy grants access to every user for every project. If access to

projects is a concern, then you can create security policies that control access to certain groups. For

example, an organization that works with a third-party provider would create a security policy for those

users, thus restricting their access to only those projects with their security policy applied.

2.

Choose Security Policy. When creating a project the security policy is selected from a drop-down list.Administrators can define security policies upfront, and empower project managers to choose the

policy that best applies to their project. A security policy can be used by one or more projects. Security

is set on a project by project basis and is inherited by all other records related to that project. Security

Policy is a mandatory field on the project record.

3.

Create Role Labels. Roles are used to define which users or groups can perform which actions for a

project. Many times an organization has a set list of role names, such as Analyst, Developer, Architect,

and Tester. You define your roles by creating an ALMRoleLabel record.

4.

Create Roles for the project. While role labels may be shared across an enterprise, the role definitions

may change from project to project. Each project determines which roles are included, which users

perform each role along with the allowed actions. Define new roles for the project by creating a new

ALMRole.

5.

Project identification and uniqueness

Over time, the number of projects produced by an organization can be large. Project uniqueness and

identifying features are needed to identify and discern one project from another. Additionally, large projects

may be subdivided into smaller projects and share the same Release version. Categories are used to classify a

project, and the release is used to identify the version of the software the project will deliver. Figure 6

illustrates the records involved in identifying and classifying projects.

Figure 6: Category and Release define project uniqueness.

The steps shown in Figure 6 can be described as follows:

Create Category Trees to classify projects. Projects are identified by a Category, which helps to classify

the product, feature, or component that the project delivers. In some organizations a need arises to

create more than one category tree. For example, a single organization may identify projects using some

combination of "product" and "service." Category Types are used to identify the classification scheme.

For example, using the example above, two CategoryType records are created, one for "product" and

1.


1 12/1/2009


7/11

one for "service." Other examples include "Product" and "Component," or "Offering" and

"Application." Once your category types are defined, you create categories for that type. Categories

can be hierarchical. First create CategoryType. Then create the categories for that type.

Create Release Labels. A Release identifies the "version" of the software. Many organizations

standardize on a nomenclature for release labels. The ALM solution supports this need by providing the

Release Label record.

2.

Choose Category. When creating a project record, the available categories appear on a drop-down list.

Choose a category that classifies this project.

3.

Choose Release. When creating the project, the available Release labels appear on a drop-down list.4.

For example, this article describes the ALM Schema that is delivered as part of ClearQuest 7.1.0.0. To

manage it, we create a Project named "Out of Box ALM," set the Category to "ALM" and set the Release to

"7.1.0.0" (see Figure 7). These three identifiers define the project. In addition, there can be only one project

with that combination of settings. This is to ensure that there is only one ALM Release 7.1.0.0 project. A

follow-on project example could keep everything the same but change the Release to "7.2.0.0."

Figure 7: Creating the Project record. The three identifiers -- name, category, and release -- define the

uniqueness of the project.

Projects often have relationships to other projects. These relationships can be established on the Related

Projects tab, as shown in Figure 8.


1 12/1/2009


8/11

Figure 8: An example of a project that has a sub-project and a prior project

As noted earlier, a large project is often broken into smaller sub-projects. To establish links between these

types of projects, you use the Super Projects and Sub Projects fields. Additionally, a single software solution

may undergo many revisions. You manage these relationships using the Prior Project or Next Project fields on

the same tab.

Project planning

The successful creation and delivery of software projects involves plans for completing work. Iterativedevelopment techniques have proved to be successful in planning and delivering software projects. Figure 9

illustrates the use of project planning records to define iterative projects.

Figure 9: Project planning for iterative, incremental software development


1 12/1/2009


9/11

The steps shown in Figure 9 can be described as follows:

Projects can be divided into Phases and Iterations, which are planned, time-boxed intervals typically

measured in weeks. For example, the IBM Rational Unified Process, or RUP, defines four phases of

Inception, Elaboration, Construction, and Transition. Another example is the four D's (Define, Design,

Develop, Deliver). Start by defining the Phase and Iteration labels used in your organization. For

example, the first Construction iteration may be labeled C1 (representing Construction Iteration One).

1.

Create Phase records. When creating these records, choose a Phase label and choose the project, as

shown in Figure 10. Create one Phase record for each Phase of your project.

2.

Figure 10: Creating a Phase record that defines a "Construction" phase for the "Out of Box ALM"

project

Create Iteration records. A Phase is divided into Iterations. Iterations focus the team on delivering

incremental value to stakeholders in a predictable manner. View the Phases and Iterations for the

project on the Plans tab. These are optional.

3.

Users of RUP would create Phase records for Inception, Elaboration, Construction, and Transition. Iteration

records using names such as "I1" for Inception iteration one, and "C1" for "Construction iteration one" would

be created to manage the iterations.

Agile users however, may take a different approach to phase and iteration names. One approach is to create a

single phase record named "Iteration." Next create an iteration record with the numeric value of the iteration.

For example, create iteration records and name them "1" and "2" and so forth. When using the system, you

will have "Iteration 1" "Iteration 2" and so forth.

The system is flexible enough to allow small teams to manage iterations while also scaling up to larger teams

who use more formalized phases and iterations. Not all teams practice iterative development, therefore, the

use of phases and iterations is optional. Because iterative development is a best practice of softwaredevelopment however, the records are provided as part of the solution.

Projects as templates

As you can see from the previous topics on projects, there are several record types involved in setting up a

project. This section introduces new features that will streamline project creation.

Copy project

Many times new projects are similar to existing projects. For example, the next version of the same project


1 12/1/2009


10/11

will have characteristics similar to its predecessor, or sub-projects will share the characteristics of the parent

project. The ability to "copy" an existing project is introduced by the ALM Solution. The "Copy Project"

command copies the structure of the project, such as the role definitions, phases and iterations, and work

configurations. It does not copy the data, such as specific request, task, or activity records. Once you have a

copy, you can then make whatever modifications are needed.

You can allow project managers to copy any project or you can establish a best practice where template

projects are created. By setting up example projects with all of the expected settings, you can provide

guidance to your project managers to copy one of the examples. For example, your organization may havemany projects that implement a packaged application such as SAP. On the other hand, your service-oriented

architecture (SOA) projects are likely to be fundamentally different. You can create an example SAP project,

and an example SOA project, and the next time one of these project types is funded, you simply copy the

example project.

Project wizard

A project wizard is provided in the new Web-based user interface that will guide you through these options.

The wizard provides the list of records to create before and after creating the project record. The creation of

projects involves more than simply creating a project record. Rather, there is a process to establishing the

project context for a team. This is analogous to purchasing an airline ticket on the Internet. The act ofpurchasing an airline ticket involves searching for flights, choosing segments, and purchasing the ticket,

followed by seat selection and online check-in. There are actions you take before and after purchasing the

ticket. The same holds true for project creation. There are actions taken before and after creating the project

record.

The wizard and project copy capabilities together provide a powerful means of creating new projects quickly

and efficiently while ensuring some consistency in settings across projects.

Next in Part 2...

Next month, we will conclude this article by describing the two remaining fundamental concepts in working

with the ALM schema in ClearQuest -- managing work, and administration and security.

Acknowledgements

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, Rick Weaver.

Resources

Learn

Learn more about Application Lifecycle Management (ALM).

Get products and technologies

Download a 30-day trial ofRational ClearQuest V7.0

Evaluate Rational ClearQuest V7.0 online.


11 12/1/2009


11/11

Discuss

Participate in the discussion forum.

A new forum has been created specifically forRational 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

About the authors

Carolyn Pampino is a Solution Architect on the Rational cross-product Green Threads team, and she currentlyfocuses 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.

Rob 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.

Trademarks | My developerWorks terms and conditions


Documents

ALM With CQ 7.1 Part 1