Software Configuration Management (SCM) is the art of both controlling and tracking changes in a software project.If software engineering is fundamentally concerned with producing quality software in a known and repeatable fashion, then SCM is the fundamental tool that drives the operation of software engineering.
Why is Software Configuration Management important?
The formal goal of a software engineering project is to deliver a set of integrated software components.In practice, software engineering is often intertwined with systems engineering; that is, the portion of a project concerned with hardware and deployment or otherwise non-functional requirements.The practical goal for any project is then to deliver a stable product which includes not only software, but the hardware specifications and configuration artifacts needed to realize the software system.Configuration Management enables the delivery of stable software and further enhances an organizations ability to deliver revisions and new features by answering the fundamental question : “How do I reproduce a change that someone has made?”. By tracking and controlling changes, SCM allows a program manager to answer that question, and make intelligent decisions based on that information. For the programmer, configuration management is important in another way – research.Proper CM allows a programmer to explore changes and features that may lead to a dead-end, without affecting the rest of the project.To summarize, CM provides reliability (artifacts are maintained in case of failure), flexibility (you can choose to go in a different direction), repeatability (you know what has changed) and isolation (research in one field won’t affect other development).Any one of the preceding four is reason enough to employ intelligent SCM; taken together it is clear that SCM must be at the core of software development.
Who is responsible for configuration management?
In a word, everyone is responsible for configuration management.From a sales manager (on commercial projects) on down to the individual programmer, configuration management needs to be a part of every day discipline.As described previously, the programmer’s fundamental concern with configuration management is one of implementation; making sure that proper procedures are followed and artifacts are revisioned often to prevent data loss and create a change trail.Architects and project management are responsible for defining the strategies to be employed by a group; in particular the way in which the implementers collaborate to achieve a stable release.Sales management or client facing people are responsible for defining and communicating what features are needed that drive that strategy, including needed release dates.
Roles within SCM
With an understanding that everyone is responsible for configuration management, the role of each individual needs to be determined.Roles can loosely be broken into two groups : planners and executors.The planner role is played collectively by the system architects, the sales team (or equivalent) and the IT management. The executor role is played by anyone who is involved in the day to day management of artifacts.On particular role that can be of high importance is that of the code librarian who watches over the repository and communicates changes as necessary (more to be said on this later). As much as can be generalized, the code librarian is the arbiter of what is available for release, which can be further generalized as the role release manager (the librarian may physically execute, the release manager decides which features and when).Architects or project managers define what reasonable branches of work need to take place.
What artifacts are appropriate for revision control?
In software development it is pretty clear that source code needs revision control, along with associated development artifacts like project configuration files, but the scope of revision control is actually much larger.Any project documentation benefits from revision control, but even more from change management.Revision control is only part of the issue; that is to maintain a history of changes.Of even greater import is to control the changes.Any document that is used to communicate in the course of a project can benefit from control management.Requirements documents, design documents, scope documents, test cases and acceptance documents are all examples of artifacts that should be controlled and revisioned, even if they are ephemeral artifacts of a particular development phase.Many of these documents are already controlled in an ad-hoc manner when using MS-Word and the ability to accept changes!Taking the concept a step further, it is beneficial to control all aspects of a software development process, from the operating system to the compilers used.Unfortunately, this extreme view of revision controlling is seldom practiced, and lead to many common problems.How many times have you been on a project where the versions of development tools or compilers has been different?Or the development system versioning is different than the production system?