Version Control

Since the establishment of software configuration management (SCM) as a formal engineering discipline, the written SCM plan has been accepted as an essential document for software development organizations. SCM engineers regard the plan as a description of the CM process and an enumeration of the CM procedures to be used on a project or program. Writing an SCM plan is often viewed as the first step in establishing the CM process for a new software development effort.

It seems so obvious that we should develop systems based on requirements, and yet it turns out to be rather hard to do and thus many organizations are doing it very badly. From a software configuration management standpoint, we could perhaps leave the whole process of requirements engineering to one side and focus on the management of requirements and thus the aspects of change control and traceability. That would perhaps be unduly ducking the issue, and, of course, we can’t resist giving an opinion anyway!

Workspace management has been an increasingly important component of CM over the years. Gone are the days when the only workspace operations were checkout, checkin, build/make, and the occasional file merge operation. Today, the workspace is at the center of a developer's interaction with the CM tool. Ideally, it is not just a file holder, but rather embodies an entire development context. More and more that context is accessed through a richer CM tool interface, from an IDE environment, or even through the file system. In the modern CM tool, the workspace must actively provide guidance to the developer rather than lying dormant waiting for a developer to manage it.

Whereas Project Management (PM) is a widely accepted, highly visible discipline, Configuration Management (CM) is too often seen as a low-level, technical discipline - a back-room activity that, while essential, does not command management attention.