Software Configuration Management is how you control the evolution of a software project.

software configuration management (SCM) is a software-engineering discipline comprising the tools and techniques (processes or methodology) that a company uses to manage change to its software assets. The introduction to the IEEE "Standard for Software Configuration Management Plans" [IEEE 828-1998] says this about SCM:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing structure for identifying and controlling documentation, code, interfaces, and databases to support all life-cycle phases

• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy

• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Clearly, software is easy to change—too easy. And not only is it easy to change, but it is unconstrained by the physical laws that serve as the guardrails of what is possible with hardware systems. Software is bounded only by the limits of the human imagination. Uncontrolled and undirected, imagination can quickly give rise to nightmare.

Today most software project teams understand the need for SCM to manage change to their software systems. However, even with the best of intentions, software projects continue to fail because of problems that could have been avoided through the use of an SCM tool and appropriate processes. These failures are reflected in poor quality, late delivery, cost overruns, and the incapability to meet customer demands.

To understand software configuration management, you might find it easier to look first at configuration management in a hardware-development environment. Hardware systems have physical characteristics that make the problems caused by the lack of sound configuration management easier to see.

For example, consider a personal computer. A computer has a processor, a mainboard, some memory, a hard drive, a monitor, and a keyboard. Each of these hardware items has an interface that connects it to other hardware items. Your mouse has a plug, and your computer has a port into which you plug your mouse, and, voilá, everything works.

If the plug on the mouse was not compatible with the port on the computer, there would be no way to connect the two pieces of hardware into a working system. Throughout the computer, there are many other similar interfaces. The processor and memory plug into the mainboard, the hard drive plugs into the computer, and the printer, monitor, and keyboard all have interfaces.

When the hardware is manufactured, the interfaces that are essential for the operation of the final system are easily seen. Therefore, they are well known and are carefully examined whenever changes are made to the hardware design.

For a hardware system, configuration management has the following aspects. Each system is numbered or identified and also has a version number. Each version number identifies different designs of the same part. For example, the model year for a car is a version number of that car. It is a 2003 Honda CRV, a 2004 Honda CRV, and so on. When the design of a hardware system is changed, the system gets a new version number.

A hardware system can be made up of hundreds, thousands, or tens of thousands of parts. The next thing that must be recorded is which versions of these parts go together. In manufacturing terms, this is often called a bill of materials. The bill of materials lists all the parts and specifies which version of each part should be used to build the system.

Parts are assembled into bigger parts, which simplifies the manufacturing process for large systems. In the personal computer example, you can say what version of the mouse, hard drive, processor, and monitor go together to make a complete system. Each of these parts, such as a hard drive, is made of many, many subparts, all of which must go together to have a working unit.

Software configuration management deals with all of the same problems as hardware configuration management (and more because of the lack of the guardrails that the laws of physics provide). Each software part has an interface, and software "parts" are plugged together to form a software system. These software "parts" are referred to by different names, such as subsystems, modules, or components. They must be identified and must have a version number. They also must have compatible interfaces, and different versions of parts can have different interfaces. Ultimately, you need a bill of materials to see which versions of which components make up the entire software system.

However, software configuration management is much harder to get right because software is much easier to change than hardware. A few keystrokes and a click of the Save button, and you've created a new version of the software. Unlike hardware, software manufacturing is very fast and can be performed hundreds of times a day by individuals on a software team. This is usually referred to as "performing a software build" or "building the software."

In this dynamic, changing environment, the discipline of SCM is brought to bear to ensure that when a final version of the entire software system is produced, all of the system's component parts can be brought together at the same time, in the same place, and can then be plugged together to work as required. Although most software project teams understand that they need SCM, many fail to get it right—not only because SCM is complex, but also because there isn't a clear understanding of specifically what a good SCM system should do. To begin to create that understanding for you, the rest of this chapter discusses key best practices of SCM in detail and introduces the concepts of the SCM tools and processes that are used to implement those best practices.

SCM Best Practices

When implementing SCM tools and processes, you must define what practices and policies to employ to avoid common configuration problems and maximize team productivity. Many years of practical experience have shown that the following best practices are essential to successful software development:

• Identify and store artifacts in a secure repository.

• Control and audit changes to artifacts.

• Organize versioned artifacts into versioned components.

• Organize versioned components and subsystems into versioned subsystems.

• Create baselines at project milestones.

• Record and track requests for change.

• Organize and integrate consistent sets of versions using activities.

• Maintain stable and consistent workspaces.

• Support concurrent changes to artifacts and components.

• Integrate early and often.

• Ensure reproducibility of software builds.

rgds