The first issue is Phase Identification. As simple as it may sound, knowing where you are in the SDLC or SDL flow is not always obvious. The reason behind the difficulty is that different parts of a software application may be at different phases at any point in time. For example, the modifications to an accounting report may be ready for testing while a program changed to fix tax calculation bugs is ready to be released to production. To make matters worse, the new bug found in the general ledger posting programs hasn’t been fixed and requires more work.

With so many programs in different development phases, how do you define and communicate which versions of programs are in a specific phase? In other words, how do you know what programs you have at any time in any phase? As the number of developers and the number of programs increase, the problem can get progressively worse.

The second issue, Phase Transition, can also be confusing. Making the transition from one phase to the next often is more complex than it first appears. You need to get answers to several questions each time you move from one phase to another. These questions include:

• Which programs are ready to move to the next phase?

• Has the development team documented and approved the phase transition?

• Is the receiving phase prepared to receive the migrated objects?

• What is the residual impact to the receiving phase of migrating objects?

The last of the common issues with software development is activity coordination. It is important that all changes to objects and phase configurations are communicated to all interested parties and agreed to by all necessary parties. Make sure objects aren’t copied to a new place without prior notice or approval. Document every change and provide a method to undo changes if needed.

Regardless of the specific software development method you use, refer to these common needs for control throughout the development process:

• Baseline identification—It is important for any software project to be able to identify which version, or collection of object versions, of an application exist in any defined collection, or configuration. For example, you need to know which versions of the program are currently in production, which versions are being tested, and what your developers are currently modifying.

• Control of changes—Since it is almost guaranteed that you will change some of your software, either to address problems or enhance the functionality, you need to control how you change those items. Change control includes the ability to enforce rules that govern how you change items, who can change them, and when you can change them.

• Communication—Another common need in any business endeavor is communication. Since software applications are composed of programs and other components that must work together, it is crucial that all interested parties are in the loop throughout the change process. Good communication when using any model is essential to ensure your software satisfies its intended requirements.

• Repeatable process—Doing anything well once is good, but doing it well over and over again increases product quality and reduces costs. Software control provides the ability to learn from what you didn’t do well last time, implements controls to keep the bad stuff from happening again, and helps you do a better job next time. In short, good software control impacts your bottom line by minimizing loss.

The traditional software configuration management (SCM) process is a collection of best practices for handling changes in software projects. It is up to each organization to implement tools and techniques that identify both the functional and physical attributes of software at various points in time, and then perform systematic control of changes. This application of SCM allows you to maintain software integrity and traceability throughout the SDLC and proactively manage all your software assets. The SCM process defines the need to trace changes and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release. SCM identifies four procedures, also called activities, that must be defined for each software project to ensure a sound SCM process. The four SCM activities are:

• Configuration identification—The process of identifying the attributes that define every aspect of a configuration item. A configuration item is a product that has an end user purpose. In the context of software development, configuration items commonly include files and schema definitions. The files in a software product can include program code, documentation, configuration files, and data files. A structured collection, or collection of specific item versions, is called a baseline, or configuration. A baseline allows the definition of a snapshot of a configuration and enables change control.

• Configuration control—Configuration control is a set of processes and approval stages required to change a configuration item’s attributes and to re-baseline them. Any changes to item versions can only occur by following defined procedures. Item version changes include adding and removing items, modifying item versions, and modifying item attributes. The Configuration Control Board (CCB) plays a central role in the configuration control process. It can have many or few members and is responsible for making decisions about changes to the system definition during the course of the development life cycle.

• Configuration auditing—Configuration auditing is the process of confirming that all system components that should be in a given baseline are present. It is how management ensures that a software project is on track and building what is actually required. As long as a software product complies with all requirements in the current baseline, and all requirements in previous baselines, the product is valid. The process of conducting an audit can be straightforward or very complex, depending on the specific requirements. At the highest level, configuration auditing checks the current software product to ensure it satisfies the baseline requirements. More in-depth validation may be required to ensure any changes since the previous baseline have not invalidated other functionality. In short, the software must still satisfy all requirements. Configuration auditing also ensures that a project satisfies all requirements. Ensuring that changes meet requirements is backward-looking validation. Ensuring all requirements have been satisfied is forward-looking validation. Configuration auditing checks that the baseline scope of work has been fully satisfied without violating existing requirements.

• Configuration status accounting—Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment in time. Basically, it is a snapshot of a configuration. It ensures that a complete and accessible record of the changes to a software system and reasons for such changes are available. The objective in configuration status accounting is to record item attributes, as well as why changes are made, when changes are made, and who made the changes. Configuration status accounting is often a reporting function that pulls the required information out of data stores created and managed by the configuration control tools in the SCM system.

SCM is far more than just version control. Version control systems keep track of all changes made to a file over time. Each change creates a new version of the file. Keeping track of changes you have made to files is important both to research a history of changes and also to have the ability to revert back to a previous specific version of a file. SCM includes version control, but also adds build management, promotion management when promoting software from one configuration to another, and unit of work management. Each SCM toolset provides different capabilities, but they all help control the software development process. TABLE 14-2 lists some common SCM tools. Each tool’s classification is either SCM or Version Control System (VCS).