Modern software configuration management (SCM) involves more than version control. It actually enables the software development lifecycle. SCM removes the chaos from team development and fosters a disciplined approach to developing a software system. To realize the benefits of SCM, it is beneficial to couple SCM practices with a process-enabled tool. The feature-rich tools available today support the day-to-day activities that are part of the software development lifecycle.

When used appropriately, process-enabled SCM tools facilitate iterative team software development in a highly dynamic environment. As SCM practitioners, we should educate and guide our customers, the members of software development teams, to exploit the application lifecycle capabilities of process-enabled SCM tools.

Why is the ‘Software Development Process’ Elusive?
Since the beginning of the computing profession, software professionals have tried to develop a process for building software systems. The term software engineering came about as members of our profession attempted to apply the rigors of an engineering discipline to the construction of software. Over the decades since the introduction of the computer, we recognized that the search for the ideal software development process is elusive. Reluctantly, we accepted that there is no turnkey process for translating requirements into a working software system. In fact, there is not even a universally accepted cookbook style approach for identifying and documenting requirements. Writing effective use cases is still an art, not a mechanical procedure. This is because knowledge acquisition is a creative activity, mastered by analysts who have honed their skills over time.

While a highly structured waterfall model was initially touted as the way to develop software systems, practitioners learned time and again how difficult it was to develop a software system according to this rigid set of steps. Through pain and failure, we learned that the way to build a software system is not to:

• elicit and document all of the requirements,
• design the system from the completed requirements,
• code the system based on the completed design,
• test the system based on the finished code, and
• ship a fully tested product to customers

Instead, we recognized that the only viable way to build a software system is to do so in an iterative manner in which requirements are refined over time as software is constructed and delivered to customers in increments. The motivation behind this approach is eloquently stated by software engineering luminary Fred Brooks in his classic paper No Silver Bullet – Essence and Accident in Software Engineering.

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. Even the simple answer – ‘Make the new software system work like our old manual information-processing system’ is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.”

What Does SCM Have to do With Software Development?
Today, some software development organizations still fail to recognize the intrinsic complexity in planning any software activity. Others recognize this complexity and have embraced iterative software development (with highly engaged customers) as the way to deal with it. These are the organizations that are likely to appreciate the ways in which software configuration management and process-enabled SCM tools can facilitate software development. These are the organizations that are also likely to champion agile software development.

So what does software configuration management have to do with iterative software development? Is software configuration management nothing more than a heavyweight process for controlling software development? The answers to these questions are “everything” and “no.” Rather than being a part of the software development process, software configuration management can and should be a way to enable this process. SCM should not be used to lock down and control software development. Instead, it should be used to bring discipline to the often chaotic team development environment.

What are Process-Enabled SCM Tools?

Early configuration management tools provided version control for source code files. By versioning source code files, changes made by one developer to one file could be preserved. Other developers could take these versions, modify them, and create new versions. The ability to version files became a prerequisite for team development. Over time, SCM tools offered integrated defect tracking since testing during the software development lifecycle identified bugs that needed to be fixed. Next came workflow automation. Tool vendors added process models and workflow engines to their SCM tools so that an organization could model and execute its software development process. Process items could model the activities that are at the core of software development lifecycle, such as gathering requirements, specifying features and functionality, designing, coding, and testing. A workflow engine could move each process item though a sequence of states as the activity modeled by the process item progressed. Over time, process modeling capabilities in the tools evolved. Today, SCM tools can model complex development processes. SCM tool users have come to expect flexible and extensible process models that can be adapted easily as an organization’s processes change. In addition, SCM tools users now look for an integration between requirements management and core SCM features. The need to ensure that a software system satisfies an evolving set of requirements is what drives this integration. Customer expectations and government regulations now make traceability from requirements to source code files a requirement for the software development lifecycle.

How can Process-Enabled SCM Tools Facilitate Team Development?

Today, process-enabled SCM tools facilitate team development by making possible the activities that are part of a software development lifecycle. These activities include:

• capturing and refining requirements through iterative development with engaged customers,
• identifying, sequencing, and tracking development tasks,
• keeping the code base active, yet stable during development,
• building and deploying to test environments, and
• identifying, tracking, and fixing defects.

Capturing and refining requirements through iterative development with engaged customers: No matter the size and scope of the software development project, the project team needs to capture requirements to design and develop the software. Traditionally, requirements management was separate and distinct from software configuration management. The distinction is becoming blurred with the growth of process-enabled SCM tools. Requirements are an asset that needs to be tracked and managed like any other software artifact. A growing number of SCM tool vendors provide an integration between requirements management and traditional SCM features so that requirements can be traced to the source code files that implement them. This helps ensure that every requirement is realized in code, which can be a challenge even for software systems of modest size and complexity. Iterative development entails refining requirements over time. SCM practices and process-enabled SCM tools can ensure that the code evolves with the requirements.

Identifying, sequencing, and tracking development tasks: Every project team needs to translate requirements into development tasks. Usually, there is a one-to-many mapping between requirements and development tasks. Accepting that every requirement cannot be finely and precisely detailed at the start, there is a need to design and code based on what is known. Whether you view design as separate from, or an integral part of coding, a series of coding tasks must be completed to realize the design. Process-enabled SCM tools facilitate the identification, sequencing, and tracking of fine grained development tasks. Some may argue that this is a project management activity that should be left to a project management tool. It is true that high-level development tasks are identified by project managers and tracked by project management tools. However, these high-level tasks are typically too coarse grained to identify the exact coding that needs to be completed. Typically, an experienced developer will break down a project management task into smaller units of work. Each unit of work will involve making a change to one or more source code files. This is where process-enabled SCM tools shine. Each fine grained task can be modeled as a process item in the SCM tool and tracked through a workflow.

Keeping the code base active, yet stable during development: Team software development involves several developers coding at the same time. The challenge is to make progress on the software system while minimizing the chaos that comes from having several developers modifying the same code base at the same time. Process-enabled SCM tools permit active development, yet keep it stable by supporting concurrent development, functional isolation, and source code file-to-process item linking.

Developing software concurrently: When a team develops a software system, it is not uncommon for two or more team members to need to modify the same file at the same time. This is the consequence of a dynamic software development environment: many developers are making changes at the same time. Early SCM tools restricted concurrent development, and thus the productivity gains from it, by requiring users to lock files before modifying them. Modern SCM tools facilitate concurrent development through reliable merge utilities. Yes, merging files requires a discipline, but other aspects of software development require working in disciplined manner. When developers are trained to use three-way merge tools, they can combine the changes made by two developers working in isolation. Of course, this assumes that each developer uses a private SCM workspace to work in isolation. Doing anything else is not a good practice.

Isolating changes by functionality implemented: Disciplined software development means keeping the work completed for different tasks separate. While it might be quicker to make several changes in one sitting, it is more difficult to identify these changes at a later time. Checking in a file or set of files after making one logical change creates a version with that change only. When making several changes in one day, it can be helpful to have each change contained in a version. This makes it much easier to back up to determine exactly when a change was introduced. Anyone who has worked in a dynamic software development environment should realize the benefit of this disciplined approach. Versioning changes frequently ensures that no code is lost and that there is a history of the changes made.

Linking source code file changes to process items: Using a process-enabled SCM tool, a developer can link new or modified source code files to a fine-grained development task. Why is this useful? Any member of the development team can use the SCM tool to see exactly what coding changes were made to implement a feature. If it becomes necessary to modify or remove this feature at a later time, no guess work is needed to identify the lines in the source code files that implement this feature.

Building and deploying to test environments: The time to think about building and deploying to test environments is as soon as coding starts, if not sooner. When using a process-enabled SCM tool, builds can be based on completed tasks, rather than on versions of source code files. This makes the description of the build content meaningful to all members of the project team, from project managers, to analysts, to developers, to testers.

Identifying, tracking, and fixing defects: Like building and deploying, the time to think about identifying and fixing bugs is as soon as coding starts. Ideally, the testing team should start testing the application following the build at the end of the first iteration. Process-enabled SCM tools support defect reporting and tracking. At any time, any member of the project team can use the process-enabled tool to list outstanding bugs. Build and deployments can be planned based on fixed defects.

Conclusion
Software configuration management fosters the activities that are at the core of the software development lifecycle. Process-enabled SCM tools help make this possible. They do this by encouraging disciplined software development, without requiring the baggage of a heavyweight process.