ALM With CQ 7.1 Part 2

Application lifecycle management with ClearQuest 7.1.0.0: Part 2 http://www.ibm.com/developerworks/rational/library/edge/08/apr08/pam...
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, in Part 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 ClearQuest

ALM 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 the
requests 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 assignment of 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.
1 of 19 12/1/2009 9:27 AM
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 the
nature 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 single
request 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.
2 of 19 12/1/2009 9:27 AM
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 determine
who (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.
3 of 19 12/1/2009 9:27 AM
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.
4 of 19 12/1/2009 9:27 AM
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 team
Represents 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
5 of 19 12/1/2009 9:27 AM
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.
6 of 19 12/1/2009 9:27 AM
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)
7 of 19 12/1/2009 9:27 AM
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.
8 of 19 12/1/2009 9:27 AM
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 of 19 12/1/2009 9:27 AM
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 will
determine 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 process
variation 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 a
matter of creating a new ALMType record.
1. You start by defining the ALMTypeLabels for your types. An ALMTypeLabel simply defines the
"name" of the type, such as "Enhancement."
2. Next you create an ALMType record. Note that you can also create TypeLabels directly from the
ALMType record, as shown in Figure 11.
10 of 19 12/1/2009 9:27 AM
Figure 11: ALMType Record
3. 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.
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 notion
of 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.
1. Start by creating your project and the roles.

2. Now create a Request & set the type attribute to "General," and associate it with your project.
3. 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.
11 of 19 12/1/2009 9:27 AM
Figure 12: Activities aggregated by a single task create a small-agile model.
4. 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.
Figure 13: Adding the Request and Task as the default for this project
5. 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.
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.
12 of 19 12/1/2009 9:27 AM
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:
1. Create Work Type Labels.

2. Create Work Types. As discussed previously, Work Types are defined to describe the nature of the
work.
3. 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.
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.
13 of 19 12/1/2009 9:27 AM
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
14 of 19 12/1/2009 9:27 AM
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 must
be 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 Baseline
record (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
15 of 19 12/1/2009 9:27 AM
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 can
now 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.
16 of 19 12/1/2009 9:27 AM
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 workload
across 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.
17 of 19 12/1/2009 9:27 AM
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 project
more 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 this
article. In alphabetical order: Kenneth Giffels, Robert W. Myers, Michael J. Saylor, and Rick Weaver.
Resources
Get products and technologies
Download a 30-day trial of Rational ClearQuest V7.0
18 of 19 12/1/2009 9:27 AM
Evaluate Rational ClearQuest V7.0 online.
Discuss
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
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
19 of 19 12/1/2009 9:27 AM

ALM With CQ 7.1 Part 2

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ALM With CQ 7.1 Part 2

Hochgeladen von

Copyright:

Verfügbare Formate

Application lifecycle management with ClearQuest 7.1.0.0: Part 2 http://www.ibm.com/developerworks/rational/library/edge/08/apr08/pam...

Application lifecycle management with ClearQuest

Date: 15 Apr 2008

This three-part article presents an overview of the concepts and

Last month, in Part One, we described the benefits of using

This month in Part Two, we'll describe in detail the ClearQuest

Work begins with a Request

Figure 3: A new request record

Figure 4: Flow of a request record

Accepting a request moves it to the completed state

Figure 6: Flow of a task

Activities complete the Task

Is owned by an individual contributor on the project team

Figure 8: Activities have a simple state transition

Understanding the Context Switch

Figure 9: State transitions and existing ClearQuest records

Figure 10: Replace State transitions with Activities

About Work Types

Figure 11: ALMType Record

1. Start by creating your project and the roles.

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

The power of "Work Configurations"

To define a Work Configuration:

1. Create Work Type Labels.

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

to implement the OpenUP process.

Builds and baselines

Figure 17: Baseline record integrated with UCM

Figure 18: Baseline record includes Activities completed

Figure 19: Build record with new ALM tab

Figure 20: Charts for managing workload

Coming next month

Get products and technologies

Download a 30-day trial of Rational ClearQuest V7.0

Evaluate Rational ClearQuest V7.0 online.

Participate in the discussion forum.

Global Rational User Group Community

About the authors

Trademarks | My developerWorks terms and conditions

Das könnte Ihnen auch gefallen