The term change management (CM) refers to the processes and tools an organization or project uses to plan, execute, and track changes to a software system. Unified Change Management (UCM) is a specific change management process developed by Rational in conjunction with our customers. UCM supports software project teams in managing the production and modification of files, directories, components, and systems. Academically speaking, change management processes consists of two disciplines:
- Software configuration management (SCM)
- Defect and change tracking (DCT)1
SCM deals with version control, workspace management, software integration, software builds, software deployment, and release processes. DCT deals with the processes and procedures by which defects, enhancement requests, and new features are submitted, evaluated, implemented, verified, and completed.
Rational has two tools that support these two disciplines, respectively. The first, Rational ClearCase®, automates SCM-related processes. The second, Rational ClearQuest®, automates DCT-related processes. By using these two tools together, you can automate UCM. Actually, you can automate almost any change management process using ClearCase and ClearQuest, but if you want out-of-the-box support for change management, then UCM is your best choice.
At Rational, we have already responded to the question, "What is the UCM process?" in a variety of ways (see References below). We offer product documentation, a book on ClearCase and UCM, and a multi-media CD that can be ordered for free. So, if you already know a little bit about UCM, you might ask, "What makes UCM better than other change management processes?" I'll try to address that question here.
Let me begin by saying that one process cannot possibly be the best fit for all software projects. Therefore, it is actually meaningless to describe UCM as better than other change management processes without doing so in the context of an actual software development project. So instead, I will describe what makes UCM different from traditional change management (CM) processes. Then you can determine for yourself how these differences would apply to your own software development projects.
A Higher Level of Abstraction with UCM
If you look at the development of software languages, it is obvious that the level of abstraction from machine code has risen considerably over the decades of computer science and engineering. At the lowest level, it's all ones and zeros, and I expect very early programmers worked at this level. Quickly came assembly language, which abstracted away the ones and zeros to provide rudimentary machine instructions such as load register X with value Y. Next came languages like Pascal and C, which provided higher order constructs such as "if-then-else" statements. And now, today, we are starting to realize the potential of "programming" visually. By modeling the behavior of software systems, we can have the code generated for us. With the introduction of these abstractions, it has become easier and faster for developers to program more complex software systems.
A similar thing is happening with respect to the evolution of CM tools. Initially, CM tools consisted only of a repository for storing versions: the contents of a file or directory at a given point in time that is stored and identified, and can be retrieved as necessary. Then came tools that allowed users to manage workspaces: a collection of specific versions of files and directories chosen for a specific task or activity. And, as lower-level abstractions such as repository and workspace become common and widely accepted, higher-order functions can be layered on top to simplify the change management process. UCM does just that. Let's look at the three key abstractions that UCM encompasses: projects, component baselines, and activities.
Typically, software development teams are organized into projects. These projects, in turn, have sub-projects, etc., so that a project may be very large or very small. From a change management perspective, organization by project serves three purposes:
- First, it identifies the team members. This is useful for security purposes and collaboration purposes, both of which are critical to good change management.
- Second, a project limits the scope of files and directories the team needs to be aware of. That is, of all the files and directories, in all the repositories a given company is using, the project identifies the precise subset that a developer assigned to that project needs to think about.
- Third, a project identifies a common integration point for the work being performed by the members of the team.
This all may sound very mundane, but the key advantage of UCM as it is implemented in ClearCase and ClearQuest is that the project is actually a physical object in the CM system that maps to a real-world project. This allows a much higher degree of automation and security than would be possible if project were not one of the CM tool's concepts. When new developers join a UCM project, for example, they are automatically given a workspace pre-configured with the right versions of the files and directories they need.
Components and Component Baselines
The second key abstraction in UCM is the notion of components and component baselines. Most version control systems include the notion of a repository that stores a collection of files and versions of those files. Some tools, like ClearCase, also organize those files into directories and store the directories and directory versions. Almost all significant development efforts have a large number of files that contain the code needed to build the system under development. These files are typically organized into directories, and this organization is often aligned with the software architecture of the system. In traditional CM systems, these key directories are not treated any differently from any other directory. UCM, however, introduces the concept of a component for distinguishing and storing these directories. A UCM component is simply a directory tree made up of files and directories that has one component root directory.
The main advantage of UCM components, as with projects, is better automation. The best way to understand this is to look at the notion of a baseline. A baseline identifies a related set of file versions. The baseline, in other words, selects one version of each file in the component. Almost all version control tools claim to have support for baselining, but if you look closely, usually you will find that they really only support the concept of labeling. Labeling is a process by which you select a label name and then attach that label name to one or more file versions. By attaching the same name to a number of different file versions, you get a pseudo-baseline.
The problem with this approach to baselining is that there are no semantics implied by the label name -- except those implied by how you use the tool. You can't look at a label and know with certainty what files are associated with it. In fact, in the time it takes you to investigate which files have that label, the label can, in the meantime, be attached to new files, moved to new versions, or removed from selected files. Of course, you can implement controls and locking to enforce your own labeling semantics, but UCM baselines solve these problems for you. These baselines are semantically rich objects that identify a "version" of a UCM component. By using them, you can be certain that all files in that component are associated with the same version. You can also be certain that the baseline will not change out from under you. Once created, UCM baselines are immutable and can be used for defining higher-level configurations. An entire system, for example, can be assembled from a set of component baselines.
Probably the most distinctive thing about UCM is that it is an activity-based change management model. What does this mean? It means that changes to files are grouped according to the reason for the change. Suppose you are fixing a defect or implementing an enhancement, for example. Whenever you change a file, you identify the reason you are making that change by declaring an activity at checkout time. An activity could be a defect, enhancement request, or simply a one-line description of your change, depending on how rigorous your defect and change tracking process needs to be. UCM supports all these types of activities -- and any others you choose to define yourself.
The primary advantage of activity-based change management is that no file can be changed without an associated reason. A secondary advantage is that the changes are integrated (or promoted) as a single, consistent whole. Most of the time, when you are making a change, you need to modify multiple files. For example, if you a fixing a defect, you may need to modify a C file and a header file. Oftentimes you need to modify many files. With UCM, all you have to do is select "activity" to record all the new versions created for all the files. Just as it does for projects and components, UCM introduces a physical activity object into the CM system that maps to a real-world object: the "unit-of-work." This has obvious, immediate benefits: When you are finished with a given task, for example, you can check in all your work at one time simply by checking in the activity.
In addition, however, there are more far-reaching automation and informational benefits. UCM moves changes through the system at the activity level. That is, when you are ready to have your changes integrated, you can "deliver" the activity. This is different from other CM approaches, which require merging a set of files or manually sending a bill of materials to someone who will then list the versions included in your change.
Actually, one of the greatest benefits of the activity-based approach is the way activities and baselines work in combination. After a component has been modified by a number of individuals, a new baseline is created. Through the use of activities and baselines, it is possible to automate the process of determining what is different between one baseline and another. This comparison between baselines produces not only a list of files that have changed from one baseline to the next, but also a list of activities! This has enormous advantages: You can automatically generate release notes, assist testers in determining the necessary set of regression tests to run after the nightly build, and so on.
This article offers just a taste of UCM's many capabilities and advantages. Fundamentally, this process for managing change on a software project -- automated through the use of Rational ClearCase and Rational ClearQuest -- raises the level of abstraction and possibilities for automation by introducing real-world objects into the CM system. These objects are projects, component baselines, and activities. If you're a long-time Rational ClearCase user, you may recognize some pieces of the UCM process in your ClearCase customization. Many of these script-based change management processes, built on top of ClearCase, played a key role in defining what UCM is -- and will continue to do so in determining what it will become!
Brian A. White (Intro by Geoffrey M. Clemm), Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction (TheADDP9 Object Technology Series). Addison Wesley Professional, 2000.
Rational Change Management CD (Free Order/View Request Form)
1 Also known as change request management (CRM), not to be confused with customer relationship management.
Brian A. White has a decade of hands-on experience with Software Configuration Management tools and methods. During his career, he has deployed SCM solutions in the industrial controls and telecommunications industries, many of them to meet ISO 9000 and SEI CMM objectives. He is currently working on configuration and change management product strategy for IBM Rational Software.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
