alm with cq 7.1 part 2

8/8/2019 ALM with CQ 7.1 Part 2

1/19

Application lifecycle management with ClearQuest

7.1.0.0: Part 2

Carolyn Pampino, Rational Solution Architect for GreenThreads, IBM

Robert Pierce, Advisory Information Developer, ClearTeam Group, IBM, Software Group

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 second

of a three-part series, this article discusses managing work in the ALM environment. This content is part of

the The Rational Edge.

Date: 15 Apr 2008

Level: Introductory

Activity: 992 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.

Last month, inPart One, we described the benefits of using

ClearQuest and the ALM package as your change management

(CM) solution and present both the concepts and design goals of

ALM in ClearQuest.

This month in Part Two, we'll describe in detail the ClearQuestALM solution and present 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. Next month, we'll conclude by explaining how to integrate ClearQuest ALM with your

current tools and processes, such as IBM Rational RequisitePro, and we'll include some advice to help

you get started.

Managing work

Projects set the context for our work; we then must do work to complete the project. Throughout the

development of a software solution many activities need to be performed to ensure that all of the work is

completed. The work records contained in the ALMWork package provide a way of keeping track of therequests and tasks that your team needs to address during the development cycle. In previous versions of

ClearQuest work was managed by creating a record type for each item to be managed (Defect, Change

Request, etc.). In the ALM schema, however, the focus is on the assignmentof work to team members. The

ALM schema provides the primary record types for managing work, which are called: Request, Task, and

Activity.

A Request is a new record type designed to allow anyone to submit petitions to the team, such as a

request for a new feature (enhancement) or a defect report. However, requests are not limited to just

features or defects. A request can come in any type defined by the project team.

A Task is a record that commits a team to "act" on a request within the context of a specific project.

cation lifecycle management with ClearQuest 7.1.0.0: Part 2 http://www.ibm.com/developerworks/rational/library/edge/08/apr

9 12/1/2009


2/19

Multiple Tasks can be associated with a Request. In some cases, many Tasks may be required to

complete a single Request. Alternatively, a single Request might be addressed in more than one project.

An Activity is a unit of work assigned to an individual. A Task commonly requires more than one

person to complete all of the work involved, therefore Activities collectively complete a Task. Multiple

Activities can be associated with a Task. A testing task provides a good example. A single Test task can

involve updating the test plan, creating test cases, creating test scripts, and running the tests. The task is

not completed until all activities are complete.

Each of these three record types can themselves be assigned "types" (discussed below) to further refine thenature of the work.

In addition to work assignments, there are often questions or comments about the work. Therefore, a

Comment record is also provided:

A Comment is a device for communicating with the record owner. Comments can be associated with

Requests, Tasks, and Activities, and are used for questions, comments, and responses. This is different

from the existing Notes record in ClearQuest. A comment in this model is a record in ClearQuest rather

than a concatenated string used in the notes package.

Figure 1 illustrates relationships among Requests, Tasks, Activities, and Work Types.

Figure 1: The primary Work records. Requests define the "need" and where it was "found." Tasks

define the work needed to complete the request for a project. Activities are assigned to individuals and

collectively complete the task. Work Type identifies the nature of the work.

All work begins with some form of Request. While the Request describes the identified need and is owned by

any stakeholder on the project, Tasks and Activities are the records that track the work that is assigned and

must be completed in order to resolve the Request. This allows you to compare the number of requests to the

number of committed tasks. This also allows Project Managers to see how much work is involved in each

request, and how much of the work is completed or outstanding. Additionally, there are times when a singlerequest may impact more than one project. This separation of requests for work and the commitment to do

work allows each impacted project to manage the Task as it relates to the satisfying the Request in that

specific project context.


9 12/1/2009


3/19

Figure 2: Using the Work records. Requests are triaged; tasks are created for projects. Activities

complete the task, which is reviewed, and the request is closed.

Figure 2 further illustrates the flow for working with these new record types. Each arrow represents the

parent/child relationships between records.

Requests describe the "need" and identify where the issue was found.

Requests are triaged to determine if and when they will be addressed.

Tasks are created for a project, and related to the Request.

Activities are defined that collectively complete the Task.

Activity status is reviewed to determine the completion of the Task.

The completion of the Task indicates the fulfillment of the Request.

The Request is accepted or rejected (if the Task is not completed satisfactorily).

Work begins with a Request

The Request record is the starting point for initiating work. Any stakeholder submits the Request, periodically

checks its status, and responds to any questions or comments. The schema's user privileges settings determinewho (that is, users, groups, or roles) may submit new Requests, as shown in Figure 3. A Request:

Contains all the information related to where and why the Request was generated. It is related to a

category that provides further classification for identifying where the need was found (e.g. product,

feature, component, service).

Request Type identifies the nature of the request. Common examples include: Enhancement, New

Feature, and Defect. However, the Request can be expanded to cover any type of request for work.

Taking the IBM Rational Unified Process, or RUP, as an example, you could create a Request to

"Initiate an Iteration."

Is mastered at the submitter's site.

Is owned by the submitter.Can have Comments (and questions) added to it.

Contains references to all Tasks associated with it.


9 12/1/2009


4/19

Figure 3: A new request record

Some fields shown in Figure 3 are mandatory. When the "project found in..." is set, the security context on

the history tab is automatically set to that of the project. Headline, Type, and Severity are all that are left for

the required fields.

The state transitions for the Request are very simple as shown below. The request is either completed or it is

not, as illustrated in Figure 4.


9 12/1/2009


5/19

Figure 4: Flow of a request record

Accepting a request moves it to the completed state

A request can be withdrawn or rejected. Once in the rejected or withdrawn state, it can be re-opened. Tasks

fulfill Requests in the context of a project.

The categorization of the Request provides an indication of which team is impacted. That team reviews the

Request and determines if and when it can be addressed. If the Request will be addressed in a particular

project, a Task is created for that project and associated with the Request, as shown in Figure 5. Anyone

looking at a Request can see which Tasks are needed to fulfill it. Anyone looking at a Task can see which

Request it is intended to complete.

A Task:

Contains all information related to where the associated Request will be addressed, such as project,

category, or release

Is owned by someone on a project teamRepresents an aggregation of work spread across multiple team members

Contains references to all Activities required to complete the Task

Refers back to the Request it is intended to fulfill


9 12/1/2009


6/19

Figure 5: If the Request will be addressed in a particular project, a Task is created for that project and

associated with the Request.

Some fields are mandatory, as indicated in Figure 5. When the "project assigned to" is set, the roles and

security context on the history tab is automatically set to that of the project. Headline, Type, Severity, and

related Request (on the Related Records tab) are all that are left for the required fields.


9 12/1/2009


7/19

Figure 6: Flow of a task

The state transitions for the Task are very simple as shown in Figure 6. A task is Opened, Activated, or

Completed. When a Task is submitted it is in the Open state. Activating a Task indicates that work has begun.

Tasks can be re-opened.

Activities complete the Task

The team leads look at a Task to determine what Activities are needed to complete the Task. Often a single

Task requires the work of multiple users. An Activity is created and assigned to a single team member to

complete a discrete unit of work, as shown in Figure 7. An Activity:

Is owned by an individual contributor on the project team

Represents a single unit of work

Refers back to the Task which it helps to complete

Is optionally enabled for Unified Change Management (UCM)


9 12/1/2009


8/19

Figure 7: An Activity is created and assigned to a single team member to complete a discrete unit of

work

Some fields shown in Figure 7 are mandatory. Headline, Type, Severity, and related Task (on the Related

Records tab) are all that are left for the required fields. The Security Context on the History tab is inherited

from the related Task. Activities also have a simple state transition as seen in Figure 8. In this case, there are

four states, just as UCM has four states. Activities are Submitted, Opened, Activated, and Completed. An

activity can be Activated from the submitted state.


9 12/1/2009


9/19

Figure 8: Activities have a simple state transition

Understanding the Context Switch

There is an important context switch that deserves a little more attention. In previous versions of ClearQuest,

a record was used to capture all field information and used state transitions to "move" the record through a

process. In some cases the state transition also involved reassigning ownership of the record to a new team

member. In effect, each state could be set to represent a single unit of work by an individual on the team.

(This still works in the product and continues to be supported.)

The ALM solution provides an alternative approach. To illustrate the switch, let's use a "Defect" as the

example.

In previous versions of ClearQuest, a Defect record was used to manage all defects found in the system (see

Figure 9). The Defect record would have a set of state changes. For example, the first state might be

"Develop" and be assigned to a developer. The next state might be "Validate" and be assigned to a tester.

Figure 9: State transitions and existing ClearQuest records


9 12/1/2009


10/19

When the developer completes her work, the Defect record is transitioned to the next state, causing the

record to change ownership to the tester. This model works until you have two separate teams each wanting a

different set of state transitions. What then? You have three choices: create a new record type for the second

team, modify the state transitions of the existing Defect record type and make everyone adhere, or ignore the

request completely. With the ALM schema, the model changes (see Figure 10). The new model starts with a

Request of type Defect. All teams can use this record type. It has a simple state transition model, and is

simply used to capture information about the defect and the project within which it was found.

Next, you create a Task and determine which Project will complete the task. The selection of the Project willdetermine what Task types are available. Choosing a task type will determine the set of activities that are

needed to complete it.

Figure 10: Replace State transitions with Activities

Instead of using complex state transition diagrams to move a single record through multiple sets of users, with

this approach you can simply create a set of Activities. Because Tasks and Activities are configured on a

project-by-project basis, ClearQuest Administrators no longer need to modify the schema for every processvariation requested by project teams. The project leaders can simply configure the set of Activities they

expect to have completed for each task type. (See below for information on configuring tasks and activities

based on types.)

About Work Types

As mentioned above, Requests, Tasks, and Activities can be further refined with a "Type" attribute that

identifies the nature of the work. For example, you might have a Request with a type attribute of "Defect," a

Task of type "Fix Defect" and an Activity with type attributes of "Implement" or "Test."

Work Type definitions are customizable and available system-wide. Customizing the work type is simply amatter of creating a new ALMType record.

You start by defining the ALMTypeLabels for your types. An ALMTypeLabel simply defines the

"name" of the type, such as "Enhancement."

1.

Next you create an ALMType record. Note that you can also create TypeLabels directly from the

ALMType record, as shown in Figure 11.

2.


19 12/1/2009


11/19

Figure 11: ALMType Record

On the ALMType record, choose between Request, Task, and Activity. Then choose the type label.

Save the record and you have a new type for use by any project managed by the system.

3.

Once you have types defined, you bind the types to a project using an ALMWorkConfiguration as discussed

below.

A simple example

The ALMTypes and TypeLabels empower you to create a highly customized system for your environment. If

your organization has standardized on a process such as RUP or the IT Infrastructure Library (ITIL) you

can introduce the vocabulary into your type definitions.

But let's say you just want a bare-bones approach to managing the work for your teams. Or maybe the notionof three levels of definitions feels like more than you're ready to use, and you just want to assign work to

people and have them complete it. Some "agile" teams work this way.

You can create a bare minimum approach by creating a Type Label called "General" and creating Types for

Request, Task, and Activity, all of the type General. You can create additional Activity types if you want to

distinguish these.

Start by creating your project and the roles.1.

Now create a Request & set the type attribute to "General," and associate it with your project.2.

Next create a Task and set the type attribute to "General" and associate it with the Project and Request

that you just created. Figure 12 illustrates this approach.

3.


19 12/1/2009


12/19

Figure 12: Activities aggregated by a single task create a small-agile model.

Open the Project record and click on the ALMWork Configurations tab. Add the Request and Task as

the default for this project, as illustrated in Figure 13.

4.

Figure 13: Adding the Request and Task as the default for this project

Last, for every piece of work that needs to be completed, create an Activity (of any type). The Activity

will automatically be associated with the Task that was set at the default for the project.

5.

In this example, all work is managed by Activities. The Activities act like a work queue, where work is

assigned and completed. You will have many Activities for the project, but only one Task and one Request.

All users of this project will know about and interact with Activities; however, they need not know about

Tasks or Requests.

This approach can work for small, agile teams or small, short-lived projects where the team members simply

want to know "What work do I have to do?" For larger enterprises that are bound by regulatory requirements,

however, this model may not suffice, as you cannot trace all work back to the originating request.


19 12/1/2009


13/19

The power of "Work Configurations"

This separation of Requests, Tasks, and Activities creates a powerful new model. However, in the prior

ClearQuest model multiple record types were used to define specific state transitions. In effect, processes

could be managed by the record type and its states. The next question then becomes: How can I manage such

processes in this new model? A secondary concern involves having to manually create tasks and activities for

every request. In the original model, you simply create a record, and the states come with it. In the new model

a single activity represents a state change. That's potentially a lot of activities to create, and how can you

guarantee that the same activities are used every time?

Enter the Work Configuration record, illustrated in Figure 14. Here is where the flexibility of the new model

comes into play. To accommodate each project team's workflow, you can now configure the default set of

Activities that are required to complete the task for each project. Project and/or Process managers will be

most interested in understanding the power of this record. Other users on the team need not be aware.

Figure 14: Work Types define the nature of the work; Work Configuration defines a recommended

process.

To define a Work Configuration:

Create Work Type Labels.1.

Create Work Types. As discussed previously, Work Types are defined to describe the nature of the

work.

2.

Bind Work Types to a project with a Work Configuration record. A Work Configuration defines what

Work Types are used by the project. Additionally, they can be used to introduce process guidance by

defining a default set of work assignments for a given type.

3.

A Work Configuration allows Project Managers to establish a customized work management process on a

project-by-project basis. This is best explained with an example, so let's continue with the Defect example we

started above.

Project 'A' has a Request of type "Problem." The Work Configurations for this project (shown in Figure 15)

are as follows:

Work Configurations are created for each Activity type: type Develop, and type Validate.

Another Work Configuration is defined for the "Fix" Task record. This Work Configuration binds the

Fix Task to Project A, and creates a rule that states: when a Task of type Fix is created, minimally

create an activity of type Develop, and an activity of type Validate.

Last, a Work Configuration is used to establish a rule that says when a Request of type Problem is

created, also create a Task of type Fix.


19 12/1/2009


14/19

Figure 15: Two Projects, two processes for fixing a problem. Here you replace one-size-fits-all state

transitions with project-defined activity sets.

As Figure 15 further illustrates, on Project B you can configure a different set of activities to adhere to how

that team works. The work configurations for this project are as follows:

Here, the Work Configuration for the Task record is different. For Project B, the rule states, create

activities of type Implement, Review, or Test.

Project B also has a Request of Type Problem, and its Work Configuration sets a rule to create Task of

type Defect.

Also note that Figure 15 illustrates the ability to have a single request that is addressed by two different tasks

on two different projects. This allows for parallel development where each project team assigns and tracks

work for satisfying the request in the context of its own project.

Figure 16 shows the Work Configurations needed for Project Team B:

Figure 16: Work Configurations for managing a defect. A type of request may need a special type of

task, which may have its own set of activities. Work configurations define these process policies for a

project.

We've only shown you one example; however, the potential usage scenarios for Work Configurations are

endless. For example, you can create a Task to Initiate a Project. This task might have Activities such as

"Define Roles," "Find Team Members," "Define Iterations," and so forth. Another Task might involve the

elaboration of the Requirements with individual activities for writing use cases, defining performance

benchmarks, and so forth.

The Work Configuration allows Project Managers to establish processes on a project-by-project basis. The

ALM sample database for "OpenUP" (discussed below) illustrates how the Work Configurations can be used


19 12/1/2009


15/19

to implement the OpenUP process.

Builds and baselines

Every time the source code is modified the application is built and verified to be of sufficient quality to begin

testing. Once verified the build is "deployed" to the test servers for testing. This pattern of delivering source

code changes, building the application, and testing occurs regardless of the scope or magnitude of a release,

whether it's a green field application, a major revision of an existing application, a patch or a hotfix. When

errors are found, defects are logged and source code is modified to fix the defect. Again, the application mustbe built and deployed back to the test servers for testing. Often, knowing which build to test is left to "tribal

knowledge" -- where you need to know the right people to know which build to use.

The ALM schema supports a workflow model where iterative, parallel development and testing occurs.

Developers deliver changes after they work on and complete Development activities. Release Engineers

create Baselines, run Builds, and validate and promote Builds. Testers work on and complete Test activities.

In software development projects builds are occurring constantly. The common questions for the development

teams are: "What's implemented in the Build?" and "what's tested in the Build?" The ALM solution includes

the Build record that was introduced as part of the Build and Deployment packages in ClearQuest 7.0.0.0.

This allows the team to capture information about each build. Additionally, the ALM solution uses a Baselinerecord (see Figure 17) to track what activities are delivered in each build. The use of the Baseline, Build, and

Activity records enables testers to know what to test and to track which tests have been run against the build.

Figure 17: Baseline record integrated with UCM

The basic flow is as follows: When the release engineer conducts the build, there is an opportunity to capture

which development activities were completed. The key is to identify which activities were delivered since the

last build. A Baseline is used to capture the state of activities at a given time. Those accustomed to UCM will

recognize the term "baseline" and its association with capturing the version of the source code at any point in

time. The ClearQuest ALM solution introduces a Baseline record to ClearQuest that can be used to map to


19 12/1/2009


16/19

UCM baselines. When a baseline is created in UCM, taking a "diff" of the activities identifies which activities

are new. This list of activities can be populated in the Baseline record as shown in Figure 18. For non-UCM

users, ClearQuest queries are used to identify the list of activities, and they can be manually added to the

Baseline record.

Figure 18: Baseline record includes Activities completed

Once the baseline is taken, the build is conducted. A Build record (see Figure 19) is used to capture the status

of the build. From this record you can create a reference to the Baseline record. This links the baseline and

the build result. The status of the build is communicated on the Build record itself. The rest of the team cannow use these records to determine their next course of action. For builds that have passed, the test team can

review the Baseline record and set of completed activities. Each activity includes a link back to the primary

task, which may also include testing activities. With this new visibility into the build contents, testers can

intelligently focus their test efforts.


19 12/1/2009


17/19

Figure 19: Build record with new ALM tab

At first glance, this may sound like a lot of effort. However, with build scripting and build automation much

of this can be automated as part of the build. A Perl script is provided that will "diff" two baselines and

populate a baseline record. Another Perl script is provided to create and populate the BTBuild record. A best

practice is to incorporate the creation of the Build and Baseline records into your build scripts or IBM

Rational Build Forge project. When the build runs, use the provided Perl scripts to automatically create the

Baseline and determine the activities, then create the Build record in ClearQuest and populate the fields with

pertinent information about that build.

Managing iterations

Tasks can be assigned to Iterations of the project. This allows the project team to balance their workloadacross iterations. Additionally, charts like the one in Figure 20 can be created to see how the work is

distributed across the team. This insight helps the Project Manager to spread the workload evenly across the

team members and avoid "critical path" situations. Such charts also help the Project Manager ensure that all

work is assigned.


19 12/1/2009


18/19

Figure 20: Charts for managing workload

In Figure 20, notice also that there are five Tasks in the "No value" column. This indicates that they are not

assigned, and can act as a trigger to the Project Manager that some work is slipping through the cracks. Also

note that the Construction phase is evenly balanced across each team member, while the workload shifts in

the Transition phase as expected. By running charts such as this, Project Managers can govern their projectmore effectively, ensure all work is assigned and everyone is active, and prevent overwhelming individual

team members with too much work.

Coming next month

Next month, we will conclude this 3-part article series with administration and security requirements,

integration and coexistence considerations, and how to get started. See you then!

Acknowledgements

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

Resources

Get products and technologies

Download a 30-day trial ofRational ClearQuest V7.0


19 12/1/2009


19/19

Evaluate Rational ClearQuest V7.0 online.

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

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


alm with cq 7.1 part 2

Documents