Software Configuration Management

A How To Guide for Project Staff

By: David Tuffley

Narrated by: Virtual Voice

Every software project that has ever slipped its deadline, bloated its budget, or shipped with embarrassing defects has one thing in common: someone, somewhere, lost control of change. A line of code was altered without authorisation. A specification diverged silently from the product it described. A version was released that no one could fully account for. Configuration management — unglamorous, procedural, indispensable — is the discipline that prevents all of this. And yet it remains one of the least understood and most frequently neglected practices in software development.

Software Configuration Management: A How-To Guide for Project Staff closes that gap. Written by David Tuffley and grounded in the rigorous framework of IEEE Standard 1042, this compact, practical guide cuts through the abstraction that makes technical standards so impenetrable and delivers instead a clear, usable blueprint for managing software through every phase of its lifecycle.

The book opens by establishing what configuration management actually is: not merely version control, not just a filing system, but a comprehensive discipline that tracks every artefact a software project produces — requirements specifications, design documents, source code, test data, user documentation, executable binaries, and the libraries that bind them together. From the moment a project begins until long after the final release, every one of these entities must be identifiable, traceable, and protected from uncontrolled change.

At the heart of the guide is the concept of the baseline — a snapshot of the project at a defined point in time that becomes the foundation for all subsequent change. Tuffley explains how baselines are established, promoted, audited, and released, and why getting this right is, as he puts it, 'at the heart of more failed projects than many a project manager would like to admit.' The change control process is treated with corresponding seriousness: who has authority to approve a modification, how change requests are routed and recorded, how the impact of a proposed change must be assessed across the entire hierarchy of configuration items before a single line of code is touched.

The guide then moves into the organisational architecture that makes configuration management work in practice — the configuration control board, with its layered authorities and its separation of technical from business decisions; the three-tier library structure of dynamic, controlled, and static repositories; and the tooling ecosystem ranging from basic file management through to fully integrated, automated environments.

The second half of the book is an annotated walk through a complete Software Configuration Management Plan, section by section. This is where the guide truly earns its title. Rather than describing what a plan should contain in the abstract, Tuffley works through each section with the questions a practitioner must answer: What entities are being controlled? Who authorises changes at each level? How are baselines tied to project milestones? What happens to support tools — the compilers, the build systems — that must be archived alongside the code they produced? How are subcontractors and vendors brought within the configuration management envelope without losing visibility or control?

Whether you are a project manager building your first CM plan, a software engineer trying to understand why your organisation's change process works the way it does, or a quality assurance professional looking for a principled framework against which to measure current practice, this guide provides what the IEEE standard alone cannot: clarity, context, and a practical path forward. Software projects fail for many reasons. Configuration management failure is one of the most preventable. This book shows you how.