Configuration management: baselines, SCIs and the repository

The thinking move: stop arguing about change, start pricing it

Every inexperienced answer to "how do you handle change?" is some version of resist it. That is the wrong instinct and the exam knows it. Requirements move because stakeholders learn; the technical approach moves because engineers learn; the plan moves because the market moves. Almost every change is justified. The engineering question is therefore not whether to allow a change but what a change should cost at this moment in the project — and the whole of configuration management is one answer to that question.

Software configuration management (SCM) is an umbrella activity — it runs across the whole life cycle rather than occupying a slot in it — whose job is to manage change. It is easiest to remember as four verbs: identify change, control change, ensure that change is properly implemented, and report change to everyone who needs to know. Notice that none of the four verbs is "prevent". Notice also that a version control system does at most one and a half of them. That distinction is worth marks on its own: a VCS is a tool inside SCM, not SCM.

The unit of information: SCI

The things SCM manages are software configuration items (SCIs) — named elements of information created by the software process. An SCI can be as small as one UML diagram or one test case and as large as a complete design document. The common mistake is to assume SCIs are code. They are not: a requirements model, a test suite, a set of test data, a content asset, a deployment script and even a tool (a specific compiler version, a specific vendor SDK) are all SCIs, because if any of them changes without anyone noticing, the delivered system changes.

SCIs are rarely managed one at a time. They are grouped into configuration objects — each with a name, attributes, and relationships to other objects. Two relationship kinds matter. A compositional relationship says one object is part of another (a data model is part of a design specification). An interrelationship says a change here may force a change there (source code realises a design element; a test specification verifies that source). Those relationships are the point of the whole scheme: they let you answer "if I change this, what else must move?" before you change it, rather than discovering the answer in production.

Baseline: the asymmetry

A baseline is the IEEE's device for controlling change without blocking justifiable change: a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Read the three clauses as three separate obligations, because an answer that drops the third one is describing a version, not a baseline.

The useful consequence is an asymmetry in the cost of change. Before an SCI is baselined, its author changes it quickly and informally — that is exactly what you want while a design is still being invented. The moment it passes a technical review and is approved, it is placed in the project database and every subsequent change needs a request, an evaluation, a decision by a change authority and a written order. Baselines are therefore milestones as well as artefacts: a baseline is produced by a review, which is why the review chapter and the SCM chapter are two halves of the same idea. The common baselines are the system specification, the software requirements, the design specification, the source code, the test plans, procedures and data, and the operational system.

Worked example — BorrowBox's configuration objects

BorrowBox lends power tools from a bank of smart lockers. Its repository holds far more than an app: the requirements and design models, the app source, the locker firmware image supplied against a third-party vendor SDK, the test suites and their fixture data, and the deployment scripts. Take one apparently trivial change — the one-time collection token currently expires after 120 seconds, and support wants 300.

With no configuration objects, that is a one-line edit in the app. With them, the relationships answer honestly: the token lifetime lives in the LockerProtocol element of the design model; the app's locker_client source realises it; the firmware's token_expiry constant implements the other end of the same handshake; and two test specifications assert the old value. So the change is not one edit, it is four coordinated edits across two baselines — one of which ships to physical hardware on the street and cannot be rolled back over the air in an afternoon. That is a decision the product owner should make with the price visible, and making the price visible is what SCM is for.