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.
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. 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.
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.
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.
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.
- 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
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.
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)
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.
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
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.
- You start by defining the ALMTypeLabels for your types. An ALMTypeLabel simply defines the "name" of the type, such as "Enhancement."
- Next you create an ALMType record. Note that you can also create TypeLabels directly from the ALMType record, as shown in Figure 11.
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.
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.
- Start by creating your project and the roles.
- Now create a Request & set the type attribute to "General," and associate it with your project.
- 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.
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.
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.
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.
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.
- Create Work Types. As discussed previously, Work Types are defined to describe the nature of the work.
- 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.
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 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 126.96.36.199. 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 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.
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.
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.
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!
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.
Get products and technologies
- 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
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.