This three-part article presents an overview of the concepts and design goals of an out-of-the-box application lifecycle management (ALM) solution for IBM® Rational® ClearQuest®. Here in Part One, we will illustrate the benefits of using Rational ClearQuest and the ALM package as your change management (CM) solution and present both the concepts and design goals of ALM in ClearQuest.
In parts 2 and 3, we'll describe in detail the ClearQuest ALM solution and present the concepts of the ALM role-based user experience, which applies both to change management in the context of IBM Rational product development, and to ClearQuest customer usage scenarios.
Managing complexity in terms of governance, security, ownership, and globally distributed development (GDD), as well as ALM, creates a need for managing change. Using a CM software tool, such as ClearQuest, and defining processes around that tool can provide great benefits by helping to link and coordinate different groups or teams within the development organization, regardless of whether they are all in one building, or geographically distributed all over the world.
As illustrated in Figure 1, the fundamental premise of ALM is to facilitate processes for developing software that span multiple team roles during the project, while managing all of the content that is produced by each role along the way. Team members rely on five pillars of capability to support their development effort. They need to 1) collaborate; 2) ensure the results of their work are traceable to the originating request; 3) automate non-creative, repetitive tasks; 4) seek strategies to continuously improve; and 5) if teams are distributed they need to ensure a close connection to the software delivery chain.
Figure 1: ALM coordinates development activities to produce assets which result in software.
For example, a single software requirement can impact the design, development, build, and testing of an application, as shown in Figure 2. Each role during the software development process produces content that contributes to the design, implementation, and testing of that requirement. Understanding and managing the amount of effort involved to satisfy each requirement is critical for a team to be able to deliver on time or under budget.
Figure 2: A single request (a single new requirement) can impact every member of the software development team.
The project manager needs to have confidence that all of the requirements have been implemented and tested with sufficient quality before agreeing to deliver the solution. The challenge for software development teams is not in creating a single artifact (source code, requirement, or test case) but rather in understanding the relationships between those artifacts.
Rational ClearQuest 22.214.171.124 includes an out-of-the-box ALM solution that provides support for managing many of the challenges presented by GDD and ALM. The ALM package provides support for a streamlined, agile application development process that is both role-based and process-driven, as illustrated in Figure 3. Projects define a context for completing work and can be secured by setting security policies and defining roles. Work can be assigned to team members who are either co-located or distributed. That work is traceable to the original request, and traceable to the project that implemented the request.
Figure 3: ClearQuest ALM supports role-based development processes.
The ALM schema provides a set of records with relationships that help teams manage software development projects. The ALM schema (and packages) is designed and built to provide the benefits listed here.
- Useful to 100% of new and existing ClearQuest customers
- Provide a solution that is scalable from small teams to enterprise-wide organizations
- Support globally distributed development teams. Supports, but does not require multisite and UCM
- Delivered with ClearQuest v7.1 as a set of packages and a schema. The ALM Packages can be applied to ClearQuest 7.0.1.
- Reduce customer cost-of-ownership and improve ROI
- Provide at least 70% of functionality out-of-the box
- Reduce time to deployment by at least 50%
- Reduce the amount of administrative changes needed to support enterprise users
- Empower project managers and team leads to configure projects without impacting the schema
- Provide fundamental "building blocks" to get started
- Provide an out-of-box experience that captures ALM "best practices" which can be used as is, or extended and applied to existing ClearQuest implementations
- Provide a secure project context with role-based "allowed actions"
- Facilitate team coordination of work throughout the software development lifecycle
- Simplify the ability to support regulatory compliance initiatives, and maintain audit trails
- Provide an out-of-box sample database demonstrating support for the OpenUP exemplary process from the Eclipse Process Framework
The ALM schema's principle role is to help teams manage the work involved in delivering software projects. The ALM schema also provides useful building blocks and frameworks that facilitate custom configurations to fit into every enterprise.
There are three essential concepts to understand when working with the ALM schema in ClearQuest:
- Projects provide the context for managing work created by the members of the team. Users are granted access to projects through Security policies, and their actions are defined by their Role.
- Managing work is enabled in the form of Requests, Tasks, and Activities. The definition of activities and tasks is driven by process definitions which can change from project team to project team.
- System-wide settings can be defined for projects and managing work. These settings allow for re-use and consistent "classification" across multiple projects, and can adapt to the enterprise. These typically involve a one-time set up, or minor changes as the teams grow and evolve with their use of the system. (CQ Administrators would start here.)
This rest of this article describes the first of these fundamental concepts, how Projects provide a role-based context for work. The second and third concepts are covered in Part Two.
All work in the ALM schema is organized by a Project. The Project provides the context, access control, and role-based security model for your work. The Project Management Body of Knowledge (PMBOK) defines "Project" as a temporary endeavor undertaken to create a unique product, service, or result. In an ALM system, it is the context within which work is done, and provides traceability for the work completed during the software project's lifecycle. The Figure 4 illustrates the architecture of an ALM Project, including the objects that comprise a Project definition, system-wide settings, and existing ClearQuest User and Group administration.
Figure 4: ClearQuest ALM: Conceptual overview of projects. All work in the ALM schema is organized by a Project. The Project provides both the context and role-based security model for your work.
The rest of this section describes the records that are used to define the project.
Security is an important aspect of all project-based work. In the ALM Schema project security is defined by who has access to the project, and what they can do. The Figure 5 illustrates the record types involved in defining the security policy and roles for a project
Figure 5: Security Polices provide access, and Roles define Allowed Actions.
The steps for establishing security as shown in Figure 5 can be described as follows:
- Create Users and Groups. Existing ClearQuest deployments already have users and groups established. Use these group definitions for defining the security policy. For new ClearQuest deployments consult the ClearQuest documentation for creating users and groups.
- Create Security Policies. The use of security policies is a fundamental concept in the design. A security policy is created to define which users have access to the project. It is simply a matter of adding one or more ClearQuest groups to a security policy record. For some organizations, access control to projects may not be a significant issue. If this is the case, you can simply create one security policy and add all ClearQuest groups to it. This security policy grants access to every user for every project. If access to projects is a concern, then you can create security policies that control access to certain groups. For example, an organization that works with a third-party provider would create a security policy for those users, thus restricting their access to only those projects with their security policy applied.
- Choose Security Policy. When creating a project the security policy is selected from a drop-down list. Administrators can define security policies upfront, and empower project managers to choose the policy that best applies to their project. A security policy can be used by one or more projects. Security is set on a project by project basis and is inherited by all other records related to that project. Security Policy is a mandatory field on the project record.
- Create Role Labels. Roles are used to define which users or groups can perform which actions for a project. Many times an organization has a set list of role names, such as Analyst, Developer, Architect, and Tester. You define your roles by creating an ALMRoleLabel record.
- Create Roles for the project. While role labels may be shared across an enterprise, the role definitions may change from project to project. Each project determines which roles are included, which users perform each role along with the allowed actions. Define new roles for the project by creating a new ALMRole.
Over time, the number of projects produced by an organization can be large. Project uniqueness and identifying features are needed to identify and discern one project from another. Additionally, large projects may be subdivided into smaller projects and share the same Release version. Categories are used to classify a project, and the release is used to identify the version of the software the project will deliver. Figure 6 illustrates the records involved in identifying and classifying projects.
Figure 6: Category and Release define project uniqueness.
The steps shown in Figure 6 can be described as follows:
- Create Category Trees to classify projects. Projects are identified by a Category, which helps to classify the product, feature, or component that the project delivers. In some organizations a need arises to create more than one category tree. For example, a single organization may identify projects using some combination of "product" and "service." Category Types are used to identify the classification scheme. For example, using the example above, two CategoryType records are created, one for "product" and one for "service." Other examples include "Product" and "Component," or "Offering" and "Application." Once your category types are defined, you create categories for that type. Categories can be hierarchical. First create CategoryType. Then create the categories for that type.
- Create Release Labels. A Release identifies the "version" of the software. Many organizations standardize on a nomenclature for release labels. The ALM solution supports this need by providing the Release Label record.
- Choose Category. When creating a project record, the available categories appear on a drop-down list. Choose a category that classifies this project.
- Choose Release. When creating the project, the available Release labels appear on a drop-down list.
For example, this article describes the ALM Schema that is delivered as part of ClearQuest 126.96.36.199. To manage it, we create a Project named "Out of Box ALM," set the Category to "ALM" and set the Release to "188.8.131.52" (see Figure 7). These three identifiers define the project. In addition, there can be only one project with that combination of settings. This is to ensure that there is only one ALM Release 184.108.40.206 project. A follow-on project example could keep everything the same but change the Release to "220.127.116.11."
Figure 7: Creating the Project record. The three identifiers -- name, category, and release -- define the uniqueness of the project.
Projects often have relationships to other projects. These relationships can be established on the Related Projects tab, as shown in Figure 8.
Figure 8: An example of a project that has a sub-project and a prior project
As noted earlier, a large project is often broken into smaller sub-projects. To establish links between these types of projects, you use the Super Projects and Sub Projects fields. Additionally, a single software solution may undergo many revisions. You manage these relationships using the Prior Project or Next Project fields on the same tab.
The successful creation and delivery of software projects involves plans for completing work. Iterative development techniques have proved to be successful in planning and delivering software projects. Figure 9 illustrates the use of project planning records to define iterative projects.
Figure 9: Project planning for iterative, incremental software development
The steps shown in Figure 9 can be described as follows:
- Projects can be divided into Phases and Iterations, which are planned, time-boxed intervals typically measured in weeks. For example, the IBM Rational Unified Process®, or RUP®, defines four phases of Inception, Elaboration, Construction, and Transition. Another example is the four D's (Define, Design, Develop, Deliver). Start by defining the Phase and Iteration labels used in your organization. For example, the first Construction iteration may be labeled C1 (representing Construction Iteration One).
- Create Phase records. When creating these records, choose a Phase label and choose the project, as shown in Figure 10. Create one Phase record for each Phase of your project.
Figure 10: Creating a Phase record that defines a "Construction" phase for the "Out of Box ALM" project
- Create Iteration records. A Phase is divided into Iterations. Iterations focus the team on delivering incremental value to stakeholders in a predictable manner. View the Phases and Iterations for the project on the Plans tab. These are optional.
Users of RUP would create Phase records for Inception, Elaboration, Construction, and Transition. Iteration records using names such as "I1" for Inception iteration one, and "C1" for "Construction iteration one" would be created to manage the iterations.
Agile users however, may take a different approach to phase and iteration names. One approach is to create a single phase record named "Iteration." Next create an iteration record with the numeric value of the iteration. For example, create iteration records and name them "1" and "2" and so forth. When using the system, you will have "Iteration 1" "Iteration 2" and so forth.
The system is flexible enough to allow small teams to manage iterations while also scaling up to larger teams who use more formalized phases and iterations. Not all teams practice iterative development, therefore, the use of phases and iterations is optional. Because iterative development is a best practice of software development however, the records are provided as part of the solution.
As you can see from the previous topics on projects, there are several record types involved in setting up a project. This section introduces new features that will streamline project creation.
Many times new projects are similar to existing projects. For example, the next version of the same project will have characteristics similar to its predecessor, or sub-projects will share the characteristics of the parent project. The ability to "copy" an existing project is introduced by the ALM Solution. The "Copy Project" command copies the structure of the project, such as the role definitions, phases and iterations, and work configurations. It does not copy the data, such as specific request, task, or activity records. Once you have a copy, you can then make whatever modifications are needed.
You can allow project managers to copy any project or you can establish a best practice where template projects are created. By setting up example projects with all of the expected settings, you can provide guidance to your project managers to copy one of the examples. For example, your organization may have many projects that implement a packaged application such as SAP. On the other hand, your service-oriented architecture (SOA) projects are likely to be fundamentally different. You can create an example SAP project, and an example SOA project, and the next time one of these project types is funded, you simply copy the example project.
A project wizard is provided in the new Web-based user interface that will guide you through these options. The wizard provides the list of records to create before and after creating the project record. The creation of projects involves more than simply creating a project record. Rather, there is a process to establishing the project context for a team. This is analogous to purchasing an airline ticket on the Internet. The act of purchasing an airline ticket involves searching for flights, choosing segments, and purchasing the ticket, followed by seat selection and online check-in. There are actions you take before and after purchasing the ticket. The same holds true for project creation. There are actions taken before and after creating the project record.
The wizard and project copy capabilities together provide a powerful means of creating new projects quickly and efficiently while ensuring some consistency in settings across projects.
Next month, we will continue this article series by describing the two remaining fundamental concepts in working with the ALM schema in ClearQuest -- managing work, and administration and security.
Special thanks to the many who have contributed their time and talent to the creation and review of this article. In alphabetical order: Kenneth Giffels, Robert W. Myers, Michael J. Saylor, Rick Weaver.
- Learn more about Application Lifecycle Management (ALM).
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
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.