Meeting of the
Los Angeles Chapter ACM

Wednesday, November 7, 2001

"Software Configuration Management"

Presented by Cheri Kaylor, Xerox Corp

Cheri Kaylor has worked in the field of Software Configuration Management (SCM) for most of her 22 year career at Xerox. She was also the head of a team that developed the SCM KPA processes and guidelines to support Level 2 compliance to the Carnegie Melon Software Engineering Institute Capability Maturity Model for Xerox's Printing Systems Group and a member of the team that did the same for Xerox's Channels Group.

Wednesday November 7, 2001.

The presentation was "Software Configuration Management-An Odyssey" by Cheri Kaylor of Xerox. This was a meeting of the Los Angeles Chapter of ACM.

Cheri started by saying that she had been in Software Configuration Management (SCM) since the second year of her professional career and that this would be a highly opinionated presentation. She welcomed interaction and feedback but reserved the right to cut us off if we were overly long. All of her experience has been at the Xerox Corporation. She said her credentials were a BA in biochemistry from Michigan State, an MS in chemistry from Cal State Fullerton and a PhD in biochemistry from USC. None of these degrees have any particular relationship to SCM. Her education provided her with the ability to train herself. When she joined Xerox in 1979 in a software development area her supervisor was the build manager and hated it. He never did new builds until it was time to deliver the software. The builds usually didn't work and were painful to correct. Cheri did not like the way things were being done and asked for her boss's job when he left. She started doing builds once a week (in contrast to prior practices, every two or three months) and was able to make the software base more reliable. Out of necessity, she and her boss "invented" SCM, before either of them even knew such a discipline existed. A recent search of the literature turned up the first citations for SCM. There were two, dated 1980, about the same time frame when Cheri and her boss were independently developing their own SCM practices.

After four years she took a break from SCM and worked on international standards. Later she was invited to join a project and do SCM for it. She said she has either been on 3 projects or 50 depending on whether you count software iterations as projects. All of her training was "on the job" until 4 years ago when she took two courses, one an overview primarily for managers and a second a more detailed course for SCM practitioners, from Systems Technology Institute. These courses were excellent and she highly recommends them.

Two Xerox organizations that Cheri was a member of attempted to implement the Level 2 Key Process Areas of the Carnegie Melon Software Engineering Institute Capability Maturity Model with the goal of becoming certified. The Level 2 "Repeatable Process" Key Process Areas are Requirements Management, Project Planning, Project Tracking and Oversight, Software Quality Assurance, Software Subcontract Management, and Software Configuration Management. Cheri noted that all of these are management-related except for SCM, which is process-related. While her organizations did not reach the "Level 2" certification, they gained a great deal by trying to implement them. Managers liked it because the procedures gave them some authority to push back against the "creeping elegance" of requirement changes that frequently cause delays and cost increases. They did not attempt to proceed further at fulfilling the CMM requirements because there was no requirement to do so in the commercial world. Cheri believes that even though they did not reach Level 2 certification, they gained a lot by trying. Much of what they learned has become "the way to do business."

Cheri explained what SCM is and is not. SCM is usually a full time job for at least one person; it recommends and/or defines the development processes, including resources such as the platform, tools, backup schemes, etc. It implements the development processes, generates reports on the running of the processes and is itself a development process. It incorporates version control, but is much more. It manages baseline identification and content, according to management direction. It often provides consulting on the use of tools and provides the first quick look at the integrity of the functionality of the product.

SCM is not free; you should allocate a minimum of 5 to 10 % of your resources to it, preferably 10%. It is very necessary. It is a case of "Pay me now or pay me later" and it's always more expensive later. SCM is not change control (changes in product feature content); that is handled by the Requirements Management Key Process Area, not Software Configuration Management. SCM doesn't do things differently every time; process flexibility is important, but having and using a process is central to SCM. Repeatability is important.

Cheri presented the 5-stage "baseline promotion" model she developed in the early 80s and has used ever since. The stages are Work-in-Progress, Ready-for-Integration, Integrated, Released, and Archived. The first stage of the promotion model is the Work-in-Progress stage, during which developers are making changes that have not yet been integrated with the work of others. When the developer has completed his work, he "promotes" the work to the Ready-for-Integration stage. This lets management and SCM know that the work is available to be integrated with the work of other developers. At some point (in Cheri's experience, at least once a week is best), all the changes at the Ready-for-Integration stage are used to produce a new iteration of the software product and the work is promoted to the Integrated stage. At some point, an existing Integrated version of the software is delivered outside of the development group, usually for testing, to be followed by release to customers. This results in promotion to the Released stage. A software product is promoted to the Archived stage when it is superceded by a new version being promoted to the Released stage. Any element of an Archived baseline may be used as the starting point for new software development, i.e., moved into the Work-in-Progress stage.

Tools are a very necessary part of SCM. One of the most important tools is the operating system of the development environment and what it provides in the way of enabling processes to be scripted in a repeatable way. An indispensable tool is some sort of "make" utility for compiling and linking to provide executable code. Using these tools (scripting and make files) requires programming skills; this is where the development of the SCM process comes in. Version control, a critical function of SCM, can be accomplished in many ways, from the simplicity of using multiple versions of the software directory tree for each stage in the promotion model, to the complexity and sophistication provided by modern version control tools. Cheri's first version control mechanism was the directory solution. The next solution she used was the Polytron Version Control Software (PVCS); the Polytron company subsequently became Intersolv, which has recently morphed into Merant, but their version control tool is still called PVCS. She later used a free unix tool called rcs. Most recently, Cheri has used tools from Rational Software, including their "base Clear Case" and "Unified Change Management Clear Case" tools. Of the two, Cheri prefers UCM ClearCase; it is easier to use and incorporates process overlays that closely resemble the overall process she has developed independently over the years.

She finished her talk with some recommendations:

For potential SCM practitioners: If you are attentive to detail, love doing things in a repeatable way, are tolerant of repetitive activities, flexible, but able to stick to your guns on important issues, and a good programmer, you will probably do well in SCM.

For managers: Allocate enough resources. Allow your SCM people to do their job; while this might sometimes seem to take longer than you would wish, in the long run you will find it time well spent. Train them not only in the tools, but also specifically in SCM. Once trained, listen to their recommendations.

For developers: Become familiar with the SCM processes and tools provided by your organization; learn to love them; in the long run they will make your job much easier. Feel free to suggest changes to processes and tools. Believe that if the product is broken it is almost always due to changes introduced by development, not due to a "bad build". Think about going into SCM yourself.

This was the third meeting of the LA Chapter year. This was a very interesting presentation, especially for anyone who has ever been on a project where software configuration management was not done properly, sometimes to the point where it was hard to tell which version of the software you were using.

Mike Walsh, LA ACM Secretary