Chapter 12. Sample Applications and Solutions

This chapter provides examples of applications and solutions developed using ClearQuest and Rational Team Concert. Some of the examples are not typical solutions and are not related to change management or work item management, but because the flexibility of the tools allows such freedom, users are taking advantage of developing applications with that powerful platform. Other examples include extensions to existing applications.

The solutions described are

• Collaborative Application Lifecycle Management (C/ALM) with Jazz-based tools

• User-defined fields, a ClearQuest solution that allows each project to define project-specific fields and pick lists without the need to change the schema

• Service level agreement (SLA), a ClearQuest solution to define SLA rules and techniques to notify and alert prior to contract breach

• ClearCase, ClearQuest, Build Forge Integrated Solution Architecture, a ClearQuest schema based on the Application Lifecycle Management (ALM) schema that is integrated with ClearCase and Build Forge to provide the customer with a governed development and build process

• Manage release promotion with ClearQuest

12.1. Collaborative ALM with Jazz-Based Tools

What is ALM and what is Collaborative ALM? There are several definitions of ALM; the Rational C/ALM project adopted the following from Forrester Research, Inc.:

The coordination of development life-cycle activities including requirements, modeling, development, build and testing, through: Process Automation, Traceability and reporting across activities of all disciplines.

Forrester has defined five criteria for an ALM 2.0 solution:

• Common services available across practitioner tools

• Microprocesses and macroprocesses governed by externalized workflow

• Practitioner tools assembled out of plug-ins

• Features available across arbitrary asset repositories

• Use of open integration standards

In the next section we explain how these criteria are met in the C/ALM solution using the Jazz platform.

12.1.1. Jazz C/ALM

Looking at collaborative teams, we see people having specific roles who are collaborating via tools to deliver a desirable change to an application. The team’s work is governed by a set of disciplines; they collaborate by sharing and exchanging data from one or more repositories.

In today’s world many teams work in a distributed environment and use Agile development methods. This requires even more collaboration during the process of a change.

The process of changing an application involves several disciplines: requirements management, design, development, build management, test management, project management, and others. In each discipline there are workflows and activities, usually performed with dedicated tools that store data in a dedicated repository. Collaboration across the disciplines is key to transforming from silo-oriented disciplines to collaborative software development teams. The lifecycle service integration layer ensures that collaboration on the server side enables cross-discipline collaboration.

C/ALM involves several disciplines and several integrated tools. Figure 12.1 describes in a schematic way the relationships and coordination of the elements we have described.

The Jazz-based Collaborative Application Lifecycle Management (C/ALM) is a solution that is based on the following:

• Data integration: Artifacts are linked across tools and repositories using RESTful interfaces (OSLC).

• Collaboration: Practitioners can link, navigate to artifacts, chat with other team members, be notified of status, and otherwise interact.

• Transparency: Team members can track the status of work across the entire lifecycle, not only in their discipline.

• Automation: Process automation improves product quality and project performance.

Figure 12.1. The coordination of people, process, information, and tools in ALM

The Rational Jazz Collaborative Application Lifecycle Management project incorporates four components (see Figure 12.2):

• C/ALM scenarios

Provide real-world, role-based and task-based user experiences that explore end user goals and their needs to access data throughout the lifecycle.

• Open Services for Lifecycle Collaboration (OSLC)

RESTful integration to unlock the information buried within development tools; open and agreed-upon interfaces are needed that allow different tools to share and exchange the data that they produce.

• Jazz Integration Architecture (JIA)

A set of interconnected technologies and specifications consisting of reference architecture, API specifications, a set of common services, and tool building blocks.

• Jazz Foundation

An implementation of the Jazz Foundation Services and optional toolkits to aid in the construction of Jazz applications.

Figure 12.2. Collaborative Application Lifecycle Management blueprint

This material has been reproduced by Addison-Wesley with the permission of International Business Machines Corporation from IBM Redbooks publication SG24-7622: Collaborative Application Lifecycle Management with IBM Rational Products (http://www.redbooks.ibm.com/abstracts/sg247622.html?Open). COPYRIGHT © 2008 International Business Machines Corporation. ALL RIGHTS RESERVED.

So the Jazz C/ALM is not only about the Jazz tools, but about the integrations between the tools that allow synchronized activities, information sharing, asset traceability, and governed processes.

See the “Resources” section at the end of the chapter for more information on ALM and Collaborative ALM.

12.2. User-Defined Fields in ClearQuest

Here is a common enterprise scenario: You have defined a schema for the entire organization and obtained agreement from all the stakeholders. You have developed the schema and deployed it. After some time a project manager requests that you add a field that is specific to a project. Later another project manager asks for just two fields that will help in the analysis phase, and the story continues with requirements for specific projects, products, or teams. If you implement these changes, after a few years you will find yourself with a schema that has many fields that are used by just a small group of practitioners.

A recent engagement we were involved with had a similar problem. We decided to create project-specific fields to address the issue. The idea was to have some fields that have general (internal) names such as UserDefined_1, UserDefined_2, and so on. The caption for those fields is blank, but the end user sees a “caption” that is actually the value of another field. The value of that field is set by the project team and not by the schema designer.

The end user sees a form similar to the one in Figure 12.3.

Figure 12.3. User-defined fields in a ClearQuest form

The form has five fields:

• The upper field is a text box control that displays the value of “project.name”; it is not mandatory to include this control, but advisable.

• The two fields in the left column are read-only fields that serve as the displayed names (captions or labels) of the fields in the right column.

• The two fields in the right column are the fields where the end user will put the values for his or her project.

In this example the project is Ground Station with two fields named Station Type and Display Type. Those names are project-specific. Each project manager can enter the relevant fields for his or her project.

Now let’s see the internals, how this is done in ClearQuest Designer.

First we have modified the Project record type. As the fields were defined for a specific project, it make sense to put these fields in the project record, but other ideas such as a designated stateless record type will work, too.

We have added two fields of type Short_String; these fields will store the names (caption or label) of the project-specific fields. In the Project record type we have added a tab for these fields, and it looks like the form in Figure 12.4.

It is clear that you can add as many fields as are required. We have found that five fields are usually enough to cover the needs of most stakeholders. You have seen the four fields that we added to the Defect record type (two fields to store the names and two to store the values).

Figure 12.4. User-defined field names in ClearQuest Designer

The names are entered with a ValueChanged hook of the field Project. Thus, when a user selects a project, a hook will copy the content of the names from the Project record.

The hook code in Listing 12.1 fills in the field names for the specific project (assuming the field Project is of type Reference and points to the Project record type).

Listing 12.1. Setting Field Names

---

proj = GetFieldValue("Project").GetValue()
If proj <> "Null" Then
 name1 = GetFieldValue("Project.FieldName_1").GetValue()
 name2 = GetFieldValue("Project.FieldName_2").GetValue()
  
 SetFieldValue "UserFieldName_1", name1
 SetFieldValue "UserFieldName_2", name2
End If

---

This strategy is very simple, but there is a caveat. If users want to query on project-specific fields, they will not find the same field names. To overcome this problem we suggest doing one or more of the following:

• Train the users on the solution strategy.

• Include help text with the internal field name.

• Add the internal name as a visible caption.

12.2.1. Defining Choice Lists

Now let us take one step forward. A project manager has requirements that are more complex. For example, suppose someone wants to have choice lists for the project-specific fields. We cannot use a Constant_List. We could use many Dynamic_Lists, a set of lists for each project, but that does not scale, especially if there are many projects.

One solution is to create a list for each field in the Project record type. The list can be stored in a Multiline_String, one value per line as in our example (another option is to separate the values with a special delimiter).

To achieve this we add one multiline field for each project-specific field. In the Project record it looks like the screen shot in Figure 12.5.

Figure 12.5. Definition of the fields in the Project record

In the Defect record type the control for the field should be a drop-down combo box. This control allows both selection and typing, to respond to the needs of all projects (a list box control allows selection but does not allow typing). The tab in the Defect form is displayed in the screen shot in Figure 12.6.

Figure 12.6. User-defined fields with a choice list: end user view of the user-defined fields in the ClearQuest client

The additional task that we have to perform is to write the hook that will populate the choice list. We suggest writing a global hook that will be called from the field choice list hook. The reason is that all the project-specific hooks will be almost identical, so by reusing code we gain simplicity and reduce maintenance costs.

The global subroutine will have two parameters as follows:

Populate_list(field2read, choices)

• The field2read parameter is the name of the field in the project stateless record type, which contains the list of values for the choice list.

• The choices parameter is a reference to the field choices object, where the values will be populated.

• The next code line shows the calling hook example. Here we use the dot notation to access the field Field2_list in the referenced stateless record type Project:

call Populate_list("Project.Field2_list" , choices)

The BASIC code in Listing 12.2 is an example of the called global subroutine.

Listing 12.2. Populating a Choice List

---

Sub Populate_list(field2read, choices)

' Purpose: Get the list values from the project record
'                and populate the choice list
' Input : field2read As String
' Output: choices As Object
' Created by: SB on 20 Nov 2008
' Date modified:

REM - read values
     flist = GetFieldValue(field2read).GetValueAsList
     if not IsEmpty(flist) then
     Keyvals = Split(Cstr(flist(0)),vbLF)
REM - populate the choice-list
           For Each keyfield in Keyvals 
             choices.AddItem(keyfield)
           Next
     end if 
End Sub

---

12.2.2. Defining Requiredness

Now let’s take another step forward.

A more complex stakeholder requirement might be to set the project-specific field requiredness differently for each project. Look at the ClearQuest behaviors table; if we want project-level behaviors, we actually need one table per project. Instead of using a table for each project, we shall use a list of pair values for each user-defined field: State::Requiredness. To achieve this solution, we will use the same method we used for the choice list. In the Project stateless record type we create fields of type Multiline_String, one field for each user-defined field.

In the screen shot in Figure 12.7 you see for Field_1 and Field_2 three supporting fields:

• The visible name of the field (caption or label)

• The choice list values

• A list of pairs of state and field permission (similar to an entry in the behaviors table)

Figure 12.7. Definition of the choice list and the requiredness

We have modified the form of the Defect record type. When the field is mandatory, the column sign becomes red. Since there is no caption for this field on the form, this is not a very visible indication. So we have changed the caption to be “==>” which is more visible and understandable. (Actually this caption is as good as any sign you see fit.) Figure 12.8 shows the Defect record type with the two mandatory fields.

Figure 12.8. Annotation of the user-defined fields when requiredness is Mandatory

Let’s review the logic behind this solution. First change the behaviors table and select the USE_HOOK permission of all states of the fields UserFieldValue_1, UserFieldValue_2 ...UserFieldValue_n.

UserFieldName_1, UserFieldName_2 ... UserFieldName_n should be READONLY, as these are the captions of the corresponding fields UserFieldValue_n (see the field behaviors in Figure 12.9).

Figure 12.9. The behaviors table definitions for the user-defined fields

To set the field permission (or requiredness) we write a global function. This function gets the name of the field in the Project record where the list of permissions for the current project is stored. The function returns to the calling hook the permission value; note that the return value is of type Long.

The calling field permission hook, for the field userfieldvalue_2, looks like this:

  userfieldvalue_2_Permission =
                  SetRequiredness( "Project.Field2_requiredness")

The BASIC code in listing 12.3 is an example of the called global subroutine.

Listing 12.3. Setting Field Requiredness

---

Function SetRequiredness( ReqFieldName )
'
' Purpose: Get the permission value from the project record
'          convert to Long and return to field_permission
' Input:  ReqFieldName As String
' Output: requiredness As Long
' Created by: SB on 27 Nov 2008
' Date modified:

     SetRequiredness = AD_OPTIONAL
     stat = GetFieldStringValue("State")

REM - Get the list values from the project record
     flist = GetFieldValue(ReqFieldName).GetValueAsList
     if not IsEmpty(flist) then
     Keyvals = Split(Cstr(flist(0)),vbLF)
REM – Get correct value for current state
           For Each keyfield in Keyvals 
             freq = Split(keyfield, "::", 2, 1)
           If( freq(0) = stat) Then
                    ' Return value is of type Long
                       SetRequiredness = ConvertEnum( freq(1) )
                       Exit For
                  End If
           Next
     end if 
End Function

---

A few comments on Listing 12.3:

• The split() function uses the textual delimiter :: and splits the keyfield string into two strings, freq(0) and freq(1).

• The function ConvertEnum() gets the permission string value and converts it to a Long.

The credit for the idea described in this section goes to Dr. Alexander Karnovsky.

12.3. Service Level Agreements (SLAs) in ClearQuest

ClearQuest is flexible enough to allow you to build various applications such as a help desk. Some of these applications require governance and monitoring of the SLAs. In this section we shall propose a method for defining SLA rules and how to monitor and alert to approaching events. We describe how to define and build an SLA in the ClearQuest schema. The solution not only verifies that the SLA is met, but also sends notifications and alerts prior to contract breach.

12.3.1. Background

An SLA is defined as a contract or agreement between the service provider and the client or the stakeholder.

We usually talk about SLAs in the context of SOA, CRM, and ERP systems. One may ask why this is relevant to ClearQuest.

We can build a help desk system with ClearQuest (as many have done), and SLA is very relevant to such a system. In the context of other applications that can be built with ClearQuest, such as defect tracking, enhancement requests, or any other change request system, we can broaden the term SLA by including internal policies and performance measurements that deal with each type of request.

Here are some examples of SLAs:

• A service provider will initially reply to a help desk ticket within four hours for a normal ticket and two hours for an urgent ticket.

• The SCCB will reply to a high-priority enhancement request within seven days.

• A blocking defect will be assigned to a solution provider within 24 hours.

Each rule includes alert and notification options:

• Who should receive an alert

• Who should receive a notification

• How long before the due date the alert should be sent

• How long before the due date the notification should be sent

In this chapter we shall propose an SLA solution that can be added to most ClearQuest schemas.

12.3.2. The Topic

In order to be able to govern the SLA rules, we need to provide the following to the administrators and the stakeholders:

• A means of defining the SLA rules in ClearQuest and the ability to easily modify them or inactivate them

• A means of checking the ClearQuest database records against the SLA rules

• A means of notifying the solution providers when a critical time is approaching

• A means of notifying the stakeholder and/or the responsible manager when a critical time is overdue

• A means of providing governance and status reports for various roles

12.3.3. SLA Definition

An SLA consists of one or more rules. Each rule is defined in a stateless record. This stateless record type contains the fields shown in Table 12.1.

Table 12.1. Suggested Fields of the SLA Record

You may add other fields to support your specific organization’s needs; some examples are shown in Table 12.2.

Table 12.2. Suggested Optional Fields of the SLA Record

12.3.4. Activate the SLA Rules

To check the ClearQuest database records against the SLA rules and activate the relevant rules, we need a time-based event, which does not exist in ClearQuest.

The way to do it is by writing an external program or script, then activating that program via tools like AT scheduler in Windows or Cron in UNIX. The program will query the database and test each record against each SLA rule.

12.3.5. Notifications

If the SLA rule is found to be valid (as explained above), we need to find out whether this is an alert or a notification and send an e-mail to the relevant person. The way to send e-mail from an external script (not via ClearQuest e-mail rules) is explained in several assets published in developerWorks. See the examples in the following:

Staff, IBM Rational, “E-mail: Sample Hooks for Users of IBM Rational ClearQuest,” IBM developerWorks, www.ibm.com/developerworks/rational/library/4513.html, 2003 (accessed February 24, 2011).

12.3.6. Providing Governance Reports

It is important to allow managers to have status reports so that they can understand the root cause of poor service and take proactive action to improve the services they provide.

Reports, charts, and queries can be easily created in ClearQuest as explained in Chapter 4, “The Data,” and in Chapter 9, “Metrics and Governance.”

12.3.7. The External Program

As mentioned previously, the solution requires writing an external program that checks the SLA rules, identifies the records in context, and sends notifications and alerts.

One approach for such a program can be to loop on each record in the database, and for each record to find if it responds to one of the SLA rules. Although this is relatively easy to program, it may require extensive resources for large databases and many rules. A similar approach is used in the following hook:

Staff, IBM Rational, “External VB Application to Do ‘Something’ with Records Not Touched in 14 Days,” IBM developerWorks, www.ibm.com/developerworks/rational/library/3895.html, 2002 (accessed February 23, 2011).

Another approach is to write an SQL query that identifies the records that respond to the SLA rules. This query requires knowledge of SQL and may be platform-dependent.

An example of such a query is demonstrated in Listing 12.4.

Listing 12.4. Sample SQL Query

---

-- Raanon Reutlinger, IBM Toronto DB2 Labs (Israel), 2010

sla_rule_check
AS
(
 SELECT h.*, s.duetime, s.notifytime
        , LAG( action_timestamp, 1)
           OVER (PARTITION BY entity_dbid
             ORDER BY action_timestamp) prev_action_ts
     FROM history h
     ,    sla_table s
     WHERE
           h.entitydef_name = s.recordtype
     AND  h.action_name = s.baseaction OR h.action_name = s.nextaction
)
,
sla_check
AS (
   SELECT s1.*
  ,CASE WHEN TIMESTAMPDIFF(8, CHAR( action_timestamp - prev_action_ts))
    BETWEEN notifytime AND duetime THEN 1 ELSE 0 END past_notify
  ,CASE WHEN TIMESTAMPDIFF(8, CHAR( action_timestamp - prev_action_ts))
    > duetime THEN 1 ELSE 0 END past_due
   FROM sla_rule_check s1
)
SELECT *
FROM sla_check
WHERE past_notify = 1
  OR past_due = 1
;

---

12.4. ClearCase, ClearQuest ALM, Build Forge Integrated Solution Architecture

This section describes a solution developed for a customer; the solution is composed of three integrated products: ClearCase to manage the software configuration control, ClearQuest to manage the change control, and Build Forge to manage the build process and automation (see Figure 12.10).

The ClearQuest ALM schema was customized to meet the required process.

Figure 12.10. Component relationships in the project

12.4.1. Understanding the Work Projects

These types of projects are the most common projects within ClearCase UCM. These are the projects where developers perform their changes. This is the UCM project where developers check out, check in, and continuously validate changes. UCM work projects have development streams, shared streams, and other stream configurations that satisfy the working requirements of the developers using the work project.

12.4.2. Developers Work on Activities within a Project

To work on ClearQuest ALM activities that are assigned to a developer, the developer must first “join” the UCM project. If the developer uses the normal Join Project wizard of UCM, he or she will eventually be left with a development stream on the UCM project with a view attached to it, as well as an integration view attached to the UCM project’s integration stream. The developer will “set” into his or her development view and associate an ALMActivity to this view using the command

cleartool setact ...

Figure 12.11 outlines the relationship between UCM and ALM objects.

Figure 12.11. UCM objects linked to ClearQuest ALM objects

Developers work on their activity in ClearCase UCM by checking out versions of elements, making changes, validating those changes, and checking their changes back into ClearCase. Once they are done with their changes, they will use ClearCase UCM to “deliver” their changes to the integration stream. At this point their development activity in ClearQuest ALM is Complete with a resolution code. However, it has not been validated yet in the integration stream.

12.4.3. Continuously Validating through a Build and Validation Process

Once changes have been delivered to the integration stream, they are candidates for the periodic build and validation process. A scheduled Build Forge project can wake up every hour (or at some other interval) and attempt to validate the integration stream. This process can be performed after every delivery, or on a time-based schedule. This type of build also does not create any records within ClearQuest ALM. Only important baselines should be logged in ClearQuest ALM. This periodic build project performs the steps outlined in Figure 12.12.

Figure 12.12. Continuous build process

12.4.4. Creating the Task to Integrate the Baseline That Includes a Defect Fix

When a request of type Defect is submitted against a project, there is normally a development task created to hold the work activities. A common extension to ALM is to create the integration task record against the projects that depend on the current project’s released baseline. This allows for the consuming projects to be notified that there is a potential defect that they may be exposed to. If the consuming projects wish to wait for the fix, they can set this integration activity to the Open state and wait for the underlying integration activity to be created. If they don’t care, they can simply close out the integration task with the appropriate resolution code.

Figure 12.13 shows the integration task relationship to the initial request.

Figure 12.13. The integration task associated with the defect request

Using the strategy outlined above, you can keep abreast of defects that may affect you as a consuming project and how the development activities for this defect are progressing.

12.4.5. Releasing Periodically through Stable Composite Baselines

Periodically it is good to expose others to your changes. A scheduled Build Forge project can perform a release for your project team. This type of release will be tracked within ClearQuest ALM. It will also use a UCM project to collect the various baselines into a composite release baseline. A typical strategy within UCM is to use a Release Project that is read-only to all components. This Release Project is used to track the composite relationship of the various baselines it is consuming. Some of the baselines being consumed may also be composite baselines.

A major benefit of using ClearQuest ALM integrated with ClearCase UCM is the ability to automatically notify consuming projects that they have an integration task to be performed on this baseline. A step within the Build Forge Release Project (step 13 in Figure 12.14) fires a process that will interrogate ClearCase’s knowledge of the baseline relationship of the previous project’s baselines and the UCM projects that consumed them. This list will be gathered and integration ALMActivities will be created on the consuming CQ-ALM project’s integration task.

To accomplish the desired functionality, the process must

1. Gather all projects that consume the last baseline in the release project

2. Look at all the activities being fixed in this baseline

3. Go up to their task level and find all integration tasks that are in the Open state

4. Make this list unique and attach the Integrate Baseline activity to each Open task of this type

If a project is found that does not have an integration task associated with it, the integration activity needs to attach to the default integration task for the ALM project. This would indicate that ClearCase thinks the project is a valid consumer but was in the Super Project list.

5. Grab the activities being fixed in this baseline and associate them with the integration activity as related records

This process will notify the integrator that there is a new set of functionality ready to be integrated. This release build project will perform the steps outlined in Figure 12.14.

Figure 12.14 shows creating a release view for the baselining of the writable components of Product_1.0. Contained within the project are also steps that deal with the Release Project. Steps 8 and 9 specifically deal with marking the composite release that consuming projects will want to integrate. This composite baseline within ClearQuest ALM simply aggregates the various baseline records with ClearQuest. To align the activities with the correct baseline records in ClearQuest, the following ClearCase command is used:

cleartool diffbl

Figure 12.14. Release build process

Figure 12.15 shows the composite baseline structure within ClearQuest ALM.

12.4.6. Working on Test Artifacts

In many cases there is a time period when the source code is frozen and only critical defects are worked on. During this time frame development of test assets may continue but not source assets. With a ClearCase UCM stream strategy you can model this in UCM as a test project with writable access only to the test assets and read-only to the source. In some cases the tests and source are contained within the same components. In this case you can simply have the test development occur on its own stream which has a foundation baseline of the frozen source baseline.

You can also use ClearQuest ALM to “turn off” development activities in the work project’s ALM work configuration by only creating Test Development activities in your project, and only assigning the test developers to a role that is allowed to work on artifacts during this stage. Figure 12.16 shows a UCM project in this phase and its related ClearQuest ALM records.

Figure 12.15. Composite baseline structure within ClearQuest ALM

Figure 12.16. Only tests allowed to be developed

12.5. Manage Release Promotion

A financial organization used to manage its software promotion process in a manual manner with spreadsheets. Promotion is a process of movement of a software configuration item from one environment to a higher environment, according to an Information Technology division work plan, to create a new software release. The environments in this context are development, integration, preproduction (or user acceptance test), and production. The organization has several IT platforms such as IBM mainframe, UNIX-based systems, and Microsoft-Windows-based systems; each one is running many applications.

The software promotion process started with preparing a detailed request for promotion (a spreadsheet form). This request required approval, and after the approval process, the task of promotion was assigned to several support teams that would actually perform the promotion activities.

The organization realized that the existing method did not provide them with the governance and quality needed, so they decided to develop a system to manage the release promotion. We shall describe that system in the following sections.

12.5.1. Current Status Assessment

This section briefly describes the current status assessment of the promotion process. Each system edition may include several applications/projects that should be released together. Project managers are responsible for preparing request for promotion documents for the configuration items (CI) in their projects. Usually each project prepares several promotion request documents, which means that a promotion for major releases includes a huge number of promotion request documents that are managed manually.

12.5.1.1. Process Lifecycle

The following tasks are performed by the various roles in the process lifecycle:

1. The requestor prepares a request for promotion by filling in a spreadsheet form.

2. The requestor asks for the approval of the Application Manager, Source Environment Manager, and Target Environment Manager.

3. Each of the three roles—Application Manager, Source Environment Manager, and Target Environment Manager—approves or denies the request for promotion.

4. After the request for promotion is approved, the project manager assigns tasks to the relevant technical support teams for doing the technical promotion.

5. Each technical support team confirms when its own task is completed.

6. The release manager manages, follows up on the process, and closes the request.

12.5.1.2. Problems in Current Status

All the operations related to the promotion process are manual, which causes the following problems:

• There is no effective permission policy or security enforcement.

• Assignment of the request for approval or for an action is performed by sending an e-mail with the request form attached to the e-mail. There is no easy way to know if the request was received or if work is in process.

• The follow-up and auditing of the process by the release manager are performed by telephone calls.

• There is no way for a manager to get real-time project status.

• In many cases two versions of the same document circulate in the system. Some even use older versions of the request form that did not conform to the IT standards.

12.5.2. Solution

It was clear to management that they needed a tool with a central database to store all requests and to be able to query the status of specific promotions and the status of a release promotion. The IT division should be able to customize the tool metadata to support the process defined by the organization. A workflow engine is required to support the defined process. Security should be enforced to support the banking regulations.

12.5.2.1. Scope

Development of an application was required to control the promotion process from one environment to the next environment only. The process starts with a request for promotion for a certain environment and ends when all of the technical tasks related to this request for promotion are completed and the promotion request is closed.

Target environment promotion rules allow promotion from the following source to target environments:

• Development to integration

• Integration to UAT (user acceptance test)

• UAT to production

12.5.2.2. Tools

The tool that was selected to develop the promotion application was IBM Rational ClearQuest. Other tools that are in use by the organization and will be integrated with this application, in the future, are IBM Rational RequisitePro and IBM Rational ClearCase.

12.5.3. Process Components

This section provides an overview of the ClearQuest components and elements that will be used in the process.

12.5.3.1. Process Roles

The activities described in the process model are performed by employees who are working in a specific development or IT operations role. A single employee can perform many roles, but any given task is performed in the context of one role. The following process roles were defined:

• ClearQuest Admin

• Application Manager

• Project Manager (usually the promotion requestor)

• Environment Responsible

• Technical Support Team (for each CI type)

• Release Manager

Only ClearQuest administrators interact directly with the schema repository. The ClearQuest administrator must grant database access to a user before the user can operate on a promotion request record.

Figures 12.17 and 12.18 demonstrate how roles are defined in the stateless record types. For each configuration item type the responsible users are defined in the CI_Type record type.

In a similar way the approvers for each environment are defined in the Application record type as shown in Figure 12.18.

Figure 12.17. Tech support roles defined in the CI_Type record: roles definition for the CICS Transaction configuration item

Figure 12.18. Approver roles defined in the Application record: defining the approvers of the Mail Management application for each environment

12.5.3.2. Process Entities

Each promotion request is represented as a record within the ClearQuest user database. The promotion request represents the basic unit of work that is authorized to be created, modified, or destroyed by the project. The activities of the process model are focused on manipulating individual records or reporting on the state of the records within a database.

Additional entities are needed to support the promotion request model. Table 12.3 describes the set of process entities defined in the promotion request system.

Table 12.3. Process Entities of the Promotion Request System

Figure 12.19 describes the relationship between all the ClearQuest record types (entities) in an ERD-like schema. Note also the fields in each entity.

Figure 12.19. The ERD of the promotion solution

12.5.3.3. Business Rules

The operations available to the ClearQuest user are controlled by the set of policies and rules that apply in the context of the user role (see Table 12.4). Access to change state actions and modify actions is controlled at multiple levels:

• Access to the user database is controlled through database subscriptions. Only authorized users are allowed to log in and operate on the records within the database.

• Within a database, access to specific actions is controlled based on the user role that is related to group membership.

• At the lowest level, control can be implemented on an individual user basis using the login ID.

• Access can also be defined based on a custom implementation.

Table 12.4. Role-Based Access Control Actions That Are Allowed to Each Role

12.5.3.4. The Process Lifecycle

A promotion request follows a process lifecycle that is captured in the ClearQuest state transition matrix. ClearQuest automatically controls the states and actions available, as well as event notification. In the next sections we shall describe the process model of stateful record types involved in the process: the promotion and the task.

12.5.4. The Promotion Process Model

This section presents the activities and states for the Promotion Request record type. The action names are annotated above the action arrow, and the responsible role that is allowed to perform the action is annotated below the action arrow (see Figure 12.20).

12.5.4.1. Process Rules

The Promotion Approval action is allowed based on the Application Name, the Environment, and the Promotion Type. Each approval requires an electronic signature. Some applications require three signatures, and others may require only one, depending on the business rules. See Figure 12.22 for the eSignature tab of the Promotion record.

The Request Promotion action will generate a task for each CI type (all CIs of the same type will be linked to a single task). Each task (related to CI type) is assigned to a corresponding technical support team. The configuration item promotion is controlled by the Task record flow.

Figure 12.21 shows the main tab of the Promotion record. The Configuration Items tab contains a field of type Reference_List to the CI record type. The tab Tasks contains a field of type Reference_List to the Task record type.

Figure 12.20. The Promotion record type workflow

Figure 12.21. A sample Promotion record: main tab

12.5.4.2. Automation

The following automations are required in the process (see Figure 12.22). The automations are implemented by hooks.

• Tasks are created automatically by the action Request for Promotion in the Promotion record. For all the CIs of the same CI_Type one task is created.

• Do not allow one task to start before the other is finished.

• Notify the task owner to start task activities.

• Allow the user to set dependency based on special conditions of specific configuration items.

• Automatic dependencies are based on the CI_Type.

For example, if the CI_Type is CICS Transaction and the transaction is a new transaction, then create three tasks and allow the tasks to be processed in parallel (the opposite of the rule that tasks should be processed in sequence).

Figure 12.22. A sample Promotion record: electronic signature tab

12.6. Resources

12.6.1. Solutions Developed by Customers and Rational Staff

O’Neill, Tony W., “SOX Compliance Using IBM Rational ClearCase and ClearQuest,” IBM developerWorks, www.ibm.com/developerworks/rational/library/05/1227_oneill/index.html, 2005 (accessed February 23, 2011).

This article explores the process of implementing IBM Rational’s ClearCase and ClearQuest tools to address Sarbanes-Oxley compliance.

Staff, IBM Rational, “Examples and Sample Schemas,” IBM developerWorks, www.ibm.com/developerworks/rational/library/05/1227_oneill/index.html, 2003 (accessed February 23, 2011).

Dubovitskiy, Pavel, “ClearQuest Email Notification Package,” http://cqadmin.org/wiki/ClearQuest_Email_Notification_Package, 2006 (accessed February 23, 2011).

This URL points to a free ClearQuest package.

This is an alternate ClearQuest Notification package. This e-mail package has several advantages over the original Rational ClearQuest Notification package: it maintains a message queue; no client setup is required; it has advanced formatting and enhanced notification conditions. It provides some SLA capabilities. The new ClearQuest EmailPlus package addresses some of the original issues as well.

12.6.2. SLA

Myerson, Judith, “Use SLAs in a Web Services Context,” IBM developerWorks, www.ibm.com/developerworks/webservices/library/ws-sla/index.html, 2002 (accessed February 23, 2011).

Staff, IBM Rational, “External VB Application to Do ‘Something’ with Records Not Touched in 14 Days,” IBM developerWorks, www.ibm.com/developerworks/rational/library/3895.html, 2002 (accessed February 23, 2011).

Greiner, Lynn, and Lauren Gibbons Paul, “SLA Definitions and Solutions,” www.cio.com/article/128900/SLA_Definitions_and_Solutions, June 18, 2009 (accessed February 23, 2011).

12.6.3. ALM and C/ALM

Gothe, Mats, Carolyn Pampino, Philip Monson, Khurram Nizami, Katur Patel, Brianna M. Smith, and Nail Yuce, Collaborative Application Lifecycle Management with IBM Rational Products, IBM Redbook (Poughkeepsie: IBM, International Technical Support Organization, 2008), www.redbooks.ibm.com/abstracts/SG247622.html (accessed February 22, 2011).

Forziati, Rich, and Mats Gothe, “Collaborative ALM Interoperability,” IBM White Paper, www-01.ibm.com/support/docview.wss?uid=swg27017757, 2010 (accessed February 22, 2011).

Pampino, Carolyn, Erich Gamma, and John Wiegand, “Scaling Agile with C/ALM (Collaborative Application Lifecycle Management),” www.infoq.com/articles/scaling-agile-with-calm, June 29, 2009 (accessed February 23, 2011).

Pampino, Carolyn, “Simplifying Application Lifecycle Management with IBM Rational ClearQuest Software,” IBM White Paper, ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14039usen/RAW14039USEN.PDF, 2008 (accessed February 23, 2011).

12.6.4. Application Lifecycle Management with Rational ClearQuest

Pampino, Carolyn, and Robert Pierce, “Application Lifecycle Management with Rational ClearQuest 7.1.0.0: Part 1,” IBM developerWorks, www.ibm.com/developerworks/rational/library/edge/08/mar08/pampino-pierce/index.html, 2008 (accessed February 23, 2011).

Pampino, Carolyn, and Robert Pierce, “Application Lifecycle Management with Rational ClearQuest 7.1.0.0: Part 2,” IBM developerWorks, www.ibm.com/developerworks/rational/library/edge/08/apr08/pampino-pierce/index.html, 2008 (accessed February 23, 2011).

Pampino, Carolyn, and Robert Pierce, “Application Lifecycle Management with Rational ClearQuest 7.1.0.0: Part 3,” IBM developerWorks, www.ibm.com/developerworks/rational/library/edge/08/may08/pampino-pierce/index.html, 2008 (accessed February 23, 2011).

12.7. Summary

In this chapter we provided some examples to solutions developed by customers using ClearQuest. The solutions usually involved customization of an existing schema or developing a new schema. Some solutions were utilities developed with scripting languages or programming languages and using the ClearQuest API to access the database.

The fact that ClearQuest is highly extensible allows many customers to develop applications that are not necessarily related to change management. Some examples are a corporate help desk, activities management, promotion management, and others.

Some solutions are based on integrations of products that build a more complete solution, for example, the Collaborative Application Lifecycle Management Jazz project that is based on RRC, RTC, and RQM. In Chapter 6, “Integrations,” we discussed tools integration; in section 12.1, “Collaborative ALM with Jazz-Based Tools,” we looked at the integration from a broader view: the entire software development and delivery process, including information sharing, traceability, and governed processes.

Section 12.2, “User-Defined Fields in ClearQuest,” presented a detailed description of a ClearQuest solution that enables project managers to define their own fields and lists without the need to modify the schema. The solution allows several projects running on the same database to see different fields and different values and behaviors.

In section 12.3, “Service Level Agreements (SLAs) in ClearQuest,” we proposed a solution to govern SLAs in the following way:

• Define SLA rules using stateless records.

• Develop an external program that queries the rules and the candidate records.

• Use e-mail for notifications and alerts.

This provides both solution providers and managers with a means to control the level of service that they provide to their customers and to prevent breaching the agreement ahead of time. To complete the solution you can use ClearQuest packages that provide charts and reports on your SLA status.

In section 12.4, “ClearCase, ClearQuest ALM, Build Forge Integrated Solution Architecture,” we described a solution that combines three integrated products. The ClearQuest packaged integrations were used to integrate with ClearCase and BuildForge. The ClearQuest ALM schema was customized to meet the required process; fields were added to include data from the customer-specific environment (embedded systems), and hooks were developed to respond to the rules the customer needed. The integrated solution enabled the customer to have better control of the development process, reduced the time to build the application, and reduced the total development costs.

The message is you can do many things, enhancing your solutions with products that allow customization and can be easily integrated.

Section 12.5 described a ClearQuest system to manage the promotion of a software release in a complex heterogeneous environment. The new system was implemented in a short time, teams were trained, and the system was deployed. Managers saw an immediate improvement in all parameters. The process is now governed and managers have full control; errors in the process were dramatically reduced. Delays have been reduced as people are notified about tasks, and management can view project status by simply executing a query.