Part X

Configuration Management

A software project produces hundreds of artefacts that depend on one another, and they all keep changing. Configuration management is the discipline that keeps them consistent while they change: it decides what to track, records every version, lets only approved changes through, and checks and reports that what is in the repository is what everyone thinks it is.

You willquote the Sommerville and IEEE 828 definitions of CM and name the five core activities and the questions each one answers.
You willclassify configuration items as basic, aggregate or derived, and tell a version from a variant from a release.
You willread and draw version graphs and Git branch/merge/tag histories, and apply semantic versioning.
You willwalk a change request through change control and the CCB, and apply all of it to the Student Enrollment exercise, the Medic case and Knight Capital.

10.1

What CM Is and Why It Matters

Picture a team of twelve developers building one system. Between them they produce requirements documents, design diagrams, source code, test scripts, build scripts, user manuals and release notes: hundreds of artefacts (an artefact is anything a project produces and keeps, whether a document, a file of code or a diagram). These artefacts are interrelated: the code implements the design, the tests check the requirements, the manual describes what the code does. So a change to one of them can quietly break many others.

Without anyone coordinating those changes, four things go wrong, and the W09 lecture names all four. Conflicting versions of files cause test failures. Changes nobody tracked turn into bugs in production. People overwrite each other's work. And documentation that no longer matches the system delays delivery.

Every symptom comes from the same root: artefacts that depend on each other change independently. Configuration management attacks the root, not the symptoms, by making change visible, deliberate and checked.

Two definitions to know exam

The guide flags two standard definitions as examinable. The first is short and easy to quote; the second breaks CM into its parts.

Definition · configuration management (Sommerville 2015)

"The process of managing changes to a software system and maintaining the integrity and traceability of the configuration throughout the system lifecycle."

Integrity here means the pieces fit together and are correct; traceability means you can follow any item back to where it came from and forward to what depends on it (for example, from a requirement to the code and tests that implement and check it).

Definition · configuration management (IEEE 828-2012)

A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to them, (3) record and report change processing and implementation status, and (4) verify compliance with requirements.

A configuration item (CI) is simply an artefact that is placed under configuration management; §10.3 defines it properly. The four numbered parts of the IEEE definition are the four classic functions of CM, and older exam questions use these names, so learn the mapping in the figure.

Four parts, four functions. Identification says what is managed, control decides which changes get in, status accounting reports where everything stands, and audit checks that the result is actually correct. The W09 lecture splits "control" further into version control and change control, giving the five activities of §10.4.

In day-to-day practice, CM is what lets a team track versions, manage dependencies between items, revert changes safely when something breaks, and audit what changed and why. It is planned up front: the configuration management plan is one of the subsidiary plans of the Project Management Plan (PMP), which Part V covers.

The real problem: managing change in a configuration exam

Definition · software configuration (W09)

A software configuration is (1) the total of all the artefacts, (2) their current state, and (3) the dependencies between them.

The third part, the dependencies, is what makes change hard. If you change a module but not the modules that depend on it, the configuration becomes inconsistent: its parts no longer agree with each other. The lecture's example is a requirement change. It ripples into the design, from there into every code module that implements the design, and into the test plan, test cases and test scripts; and the user documentation and release notes depend on the code too. Step through it below.

How one requirement change ripples through a configuration

Five kinds of artefact and the dependencies between them (W09). An arrow from A to B means B depends on A, so a change to A may force a change to B.
The client changes a requirement. On its own this is a one-line edit to a document, but it is the start of a ripple.
Two artefacts depend directly on the requirement: the design (the class diagram must now show the new behaviour) and the test plan, cases and scripts (they must test the new requirement).
The code modules implement the design, so every dependent module must change too.
Changed code has two more dependants: the tests (they test the code, so they are checked again) and the user docs and release notes, which describe what the code does.
One change touched five kinds of artefact. A team that changes only the code leaves the other four out of date, and the configuration is inconsistent. Keeping it consistent is the job of CM.

Check yourselfA software configuration has three parts. Name them, and say which one makes change hard and why.

It is (1) the total of all the artefacts, (2) their current state and (3) the dependencies between them. The dependencies make change hard: if you change one item but not the items that depend on it, the configuration becomes inconsistent.

Check yourselfMatch each part of the IEEE 828 definition to its classic CM function: (1) identify and document characteristics; (2) control changes; (3) record and report change processing and status; (4) verify compliance with requirements.

(1) Identification, (2) control, (3) status accounting, (4) audit.

In short

CM manages change to a system while keeping its integrity and traceability (Sommerville). IEEE 828's four parts are the four classic functions: identification, control, status accounting and audit.
A configuration is all the artefacts, their current state and their dependencies. Change one item without its dependants and the configuration becomes inconsistent.

10.2

Two Case Studies: Coles and Knight Capital

Two real failures show what CM saves when it works and what it costs when it is missing. The lecture uses Coles; the tutorial (T09) uses Knight Capital.

Coles point-of-sale outage, 20 March 2020 exam

A point-of-sale (POS) system is the checkout software that takes customers' payments. On 20 March 2020, a software update to Coles's POS system caused a nationwide payment failure. Customers could not pay for about 4 hours, and stores in every state closed. The stepper tells the story and shows which part of CM did which job.

Coles 2020: what failed, and what saved them

Before the update, Coles's previous stable version of the POS software was stored and versioned. In CM terms it was a baseline: a reviewed, agreed version you can return to (§10.8). The gold diamond marks it; gold means baseline or tag throughout this Part.
An update was deployed without three safeguards: (1) full regression testing across environments (re-running existing tests to check that old behaviour still works, in every setting where it runs), (2) clear rollback documentation, and (3) coordination with dependent systems such as the payment gateways. That is the root cause.
The update was incompatible with the systems around it, so payments failed across the whole country for about 4 hours, and stores in every state closed.
CM made recovery possible. Because the earlier version had been stored and versioned, the update was traceable and the dependencies were known, staff could roll back to the earlier baseline.
The lessons: even short outages cost money, reputation and goodwill, and different parts of CM do different jobs. Change control and regression testing prevent failures; version control and baselines limit the damage when one happens anyway.

Knight Capital, 2012 (T09)

Knight Capital was a share-trading firm whose software sent orders to the stock market. An update was meant to go to all eight of its trading servers, but it reached only seven. The eighth server still ran obsolete code, and it sent thousands of wrong orders, losing $440m in 45 minutes. (That is the tutorial's figure; the US regulator, the SEC, says about $460m.)

One server out of eight was enough. Knight Capital is the purest example of an inconsistent configuration: the same system ran two different versions at once. §10.13 works through the tutorial's tasks, which ask what to track and how to mitigate each risk.

Check yourselfIn the Coles outage, which parts of CM would have prevented the failure, and which limited the damage?

Prevent: version control and baselines. Limit: change control and regression testing.
Prevent: change control and regression testing. Limit: version control and baselines.
Prevent: auditing only. Limit: status reporting.
Both jobs are done by the rollback documentation alone.

B. Change control and regression testing stop a bad change going out; version control and baselines let you roll back once it has. A swaps the two roles, which is the classic near-miss.

In short

Coles 2020: an update deployed without cross-environment regression testing, rollback docs or coordination with payment systems stopped payments nationwide for about 4 h; a stored, versioned baseline allowed the rollback.
Knight Capital 2012: an update reached 7 of 8 servers; the 8th ran obsolete code and lost $440m in 45 minutes (no consistency check, no rollback plan, no audit, no coordinated deployment).

10.3

Configuration Items

You cannot manage "everything" in a project: you have to decide which artefacts are important enough to track formally. That decision is configuration identification, the first CM activity, and the things you choose are called configuration items.

Definition · configuration item (CI) exam

Configuration items are the artefacts that require configuration management: the documents or components that must be tracked and maintained under version control. (This is the answer to the T09 multiple-choice question on what CIs are.)

Three types of CI exam

The W09 lecture sorts CIs into three types, depending on how the item comes into being.

A basic CI is a single unit created by a person, such as the source file Login.java or Requirement R-101.
An aggregate CI is a named collection managed as one unit, such as a Login Module made up of code, a test and a diagram.
A derived CI is generated automatically from other CIs, such as the compiled file Login.class or the packaged build.zip.

Ask "who made it, and is it one thing or many?" A person writes a basic CI; an aggregate bundles several CIs under one name; a build produces a derived CI. (The test and diagram file names inside the Login Module are illustrative.)

Derived items need special care because you don't store them by hand: you regenerate them. They must therefore be reproducible, meaning that rebuilding them later gives exactly the same result. That is only possible if you control all three inputs: their sources, the build script, and the versions of the tools used to build them (a different compiler version can produce a different program from the same source).

Where CIs come from

CIs come from every part of the project, not just the code. Some less obvious items are CIs too, and these are the ones teams forget: build and deployment scripts, runtime configuration files, third-party libraries and drivers, and compiler versions. Knight Capital's failure was in exactly this category: a deployment process, not a line of business logic.

If changing it could change how the system behaves, it is a CI. The top row is what most people think of; the gold band is what bites. A runtime configuration file is as risky as code, and a compiler version decides what a build produces.

Check yourselfWhich of these is a derived CI?

Login.java
Requirement R-101
build.zip
A Login Module made of code, test and diagram

C. build.zip is generated automatically by a build. A and B are basic (made by a person); D is aggregate (a named collection).

Check yourselfA colleague says "we don't need to version build.zip or the compiler; we can always rebuild". What must be controlled for that claim to be true?

A derived CI is only rebuildable if it is reproducible, which requires controlling its sources, its build script and the tool versions used to build it. So the compiler version must be under CM even if the zip itself is regenerated.

In short

CIs are the artefacts that must be tracked under version control. They are basic (made by a person), aggregate (a named collection) or derived (generated, and so must be reproducible from controlled sources, build script and tool versions).
CIs come from requirements, design, code, testing and documentation, plus build/deploy scripts, runtime config, third-party libraries and compiler versions.

10.4

The Five Core CM Activities exam

CM is a lot of work, so the lecture organises it into five core activities. Each has a purpose and a set of framing questions it answers, and the questions are the easiest way to remember them: if you can say which question an activity answers, you can say what it is for.

Bold line: the purpose. Grey lines: the framing questions. Read across and the activities form a natural order: decide what to track, keep its versions, let changes in only through control, check the result, and report where everything stands. Baselining is not a sixth activity: it is where version control and change control meet.

Identification was covered in §10.3. Baselining spans version control (a baseline is a tagged, retrievable version) and change control (once something is baselined, only change control can alter it), so it gets its own section, §10.8.

Sommerville's framing, used in T09

Sommerville divides CM differently, and the T09 tutorial uses his framing. It helps to see the two side by side, because an exam answer may use either vocabulary.

Sommerville activity (T09)	What it means	Nearest lecture activity
Change management	Handling requests for change: analysing, approving and tracking them	Change control
Version management	Keeping track of the versions of components	Version control
System building	Assembling the correct versions of the components into an executable system	(derived CIs, §10.3)
Release management	Preparing and tracking the versions released to customers	Version control and baselines

Check yourselfWhich CM activity answers the questions "What's done? What's pending? What's broken?"

Auditing
Status reporting
Change control
Identification

B. Status reporting gives visibility of the current state of all items. Auditing (A) is the near miss: it asks whether things are consistent and correct and traceable, not merely where they stand.

Check yourselfSelect all that apply. Which of these are activities in Sommerville's framing of CM (the one T09 uses)?

System building
Auditing
Release management
Status reporting
Change management

A, C and E. Sommerville's four are change management, version management, system building and release management. Auditing and status reporting are from the lecture's five-activity framing.

In short

The five core activities are identification (what to track), version control (track and retrieve versions), change control (approve and make safe changes), auditing (is it consistent and correct?) and status reporting (what is the state of everything?). Baselining spans version and change control. Sommerville's framing is change management, version management, system building and release management.

10.5

Version Control: Versions, Variants, Releases

Every CI changes many times during a project. If you only ever keep the latest copy, you cannot answer "what did this look like last Tuesday, when the tests still passed?" Version control solves that.

Definition · version control (W09)

"The process of managing and tracking changes to configuration items over time." Think of the version history in Google Docs, but for a whole system, and with branches, merges and traceability added (§10.6 explains branches and merges).

It matters for five reasons, shown below. The common tools are Git, SVN and Mercurial, and teams usually host their repositories on GitHub, GitLab or Bitbucket. A repository is the store that holds every version of every CI, plus the history of who changed what.

Five reasons, one store. All five benefits come from the same thing: the repository keeps every version with its history, rather than only the latest copy.

Version, variant, release exam

These three words are easy to mix up, and the exam likes to test exactly that. The one distinction to hold on to: a version changes functionality, whereas a variant keeps the same features in a different setup. A release is about who receives it.

Term	Definition	Example	Key point
Version	A functionally different state of a CI, caused by development changes	v1.0 → v1.1 adds login	Functional change
Variant	Functionally identical, but differs in non-functional aspects such as platform or language	v1.1-Windows vs v1.1-Mac; English vs Spanish	Same features, different setup
Release	A version or variant formally delivered to users outside the development team	v2.0 stable; App Store v3.1.2	Public-facing, usually baselined
Derivation history	The recorded chain of changes and their rationale	"Bug fix #342 → improved error handling → added retry logic"	Trace and audit

Three different questions. Version: did the functionality change? Variant: same functionality, different platform or language? Release: has it been formally delivered to users outside the team? One item can be all three: "v1.1-Mac, shipped on the App Store" is a version, a variant and a release. (The three features listed in the variants are illustrative.)

Derivation is a graph, not a line exam

Version numbers look like a straight line, 1.0, 1.1, 1.2, 2.0 … but real development branches. The W09 diagram (after Sommerville) shows how. In it, an arrow means "derived from": the version at the arrowhead was made by changing the version at the tail.

The name does not tell you the parent. If you guessed V2.0's parent from its number, you would say V1.2, and you would be wrong. Sequential numbers assume development is linear, so the version-control system must record the derivation history: you cannot recover it from the names.

Semantic versioning: MAJOR.MINOR.PATCH

Semantic versioning gives each part of a version number a meaning, so a user can tell from the number alone whether upgrading is safe. A change is backward compatible if everything that worked with the old version still works with the new one. The rules: increment MAJOR for breaking changes, MINOR for backward-compatible features and PATCH for backward-compatible bug fixes; and whenever you increment a field, reset the fields to its right to zero.

Semantic versioning, one change at a time

The product is at version 2.4.7: MAJOR 2, MINOR 4, PATCH 7.
The team fixes a bug without changing any behaviour users rely on: a backward-compatible fix, so PATCH goes up by one: 2.4.8.
Next it adds a new optional feature. Old uses still work, so it is backward compatible: MINOR goes up (4 → 5) and PATCH resets to 0: 2.5.0.
Finally it removes a field from its API (the interface other programs call). Any program that used that field now breaks, so this is a breaking change: MAJOR goes up (2 → 3) and both lower fields reset: 3.0.0.

Check yourselfClassify each: (a) the app is translated into Spanish with no other change; (b) a new export-to-PDF feature is added; (c) v3.1.2 is published on the App Store.

(a) A variant: same features, different language. (b) A new version: functionality changed. (c) A release: formally delivered to users outside the team (and usually baselined).

Check yourselfA library is at 1.9.3. The team adds a backward-compatible feature. What is the new version number?

1.9.4
1.10.0
2.0.0
1.10.3

B, 1.10.0. A backward-compatible feature bumps MINOR (9 → 10; the fields are numbers, not decimals) and resets PATCH to 0. D forgets the reset; A treats a feature as a fix; C treats it as breaking.

In short

Version control manages and tracks changes to CIs over time: history, rollback, collaboration, reproducibility and release management.
Version = functional change; variant = same features, different setup; release = formally delivered outside the team. Derivation is a graph, so the VCS must record it.
Semantic versioning: MAJOR for breaking, MINOR for compatible features, PATCH for compatible fixes; reset the lower fields.

10.6

Branching and Merging with Git

Twelve developers cannot all edit the same copy of the code at once without tripping over each other, and a half-finished feature should not break the version everyone else is testing. Branches solve this by giving each change its own isolated line of development; merges bring the lines back together. Git, the most common tool, has four core concepts, and each one has a CM meaning.

Read a commit graph left to right in time. Circles are commits (versions); coloured lines are branches: main (the trunk, the shared line everyone integrates into) and feature branches. A gold diamond is a tagged commit, which is how a baseline or release is marked.

A commit is a new version, recorded with its author, time, message and parent(s). Following parents back gives the derivation history of §10.5.
A branch is an isolated line of development for a change, a variant or maintenance.
A merge (or a pull request, which is a request to merge that others review first) joins two lines, giving a version with two parents. The review on the pull request acts as lightweight change control.
A tag is an immutable label that marks a baseline or release, for example v1.2. Immutable means it never moves: v1.2 always names exactly the same commit.

The typical flow, step by step

The guide describes one standard flow. It starts from a tag, does the work on a feature branch, and comes back through a reviewed, tested pull request. Continuous integration (CI) appears here: an automated service that builds the code and runs the tests on every change (§10.10). Running CI on every branch keeps main healthy (Atlassian).

From tag to tag: a feature branch and a pull request

Start from a tag. main is at the release tagged v1.2, a known-good baseline.
Create a feature branch from that tag. Work on the new feature now happens on its own line, so it cannot disturb main.
Make commits on the branch, each a new version with author, time, message and parent. Meanwhile other people keep committing to main; the two lines are isolated from each other.
Open a pull request. CI runs (the code is built and the automated tests run) and peers review the change. Together these act as lightweight change control: nothing joins main until it builds, passes and is approved.
Merge to main. The merge commit has two parents, the latest main commit and the last feature commit, so the derivation history records both lines. (If both lines had changed the same lines of the same file, a person would have to resolve the clash, called a merge conflict, before merging; short-lived branches and CI on every branch keep these rare.)
Tag the new release, here v1.3. The tag is immutable, so v1.3 is now a baseline you can always rebuild or roll back to.

A whole history: trunk, feature branches, a maintenance line and tags

Put several flows together and you get a picture like the one below. It has the same shape as the derivation graph of §10.5: the trunk moves forward, feature branches split off and merge back, and a maintenance branch (often called a release branch) splits off an old release to fix it without dragging in newer, unfinished work. That is the V1.1b → V1.1.1 "maintenance line off V1.1" from the W09 diagram.

Lanes are branches; gold diamonds are tags. main carries the releases. Each feature branch isolates one change until review and CI pass. The maintenance branch lets the team ship v1.1.1, a fix to the old v1.1 that some customers still run, without shipping the unfinished login work that is already on main. (Branch names are illustrative.)

Check yourselfSelect all that apply. In CM terms, which statements about Git are correct?

A tag is an immutable label that can mark a baseline or release.
A merge commit has exactly one parent.
Review on a pull request acts as lightweight change control.
A branch can isolate a change, a variant or maintenance work.
Commit messages replace the need for a derivation history.

A, C and D. A merge has two parents (B is wrong), and the commits, with their parents, are the derivation history; they don't replace it (E is wrong).

Check yourselfCustomers on v1.1 need an urgent security fix, but main already contains half-finished work for v1.2. How do you ship the fix using the ideas above?

Branch a maintenance line from the v1.1 tag (not from main), make and review the fix there, run CI, and tag it v1.1.1 (a PATCH bump). Because the tag v1.1 is immutable, you know exactly what you are starting from, and none of main's unfinished work reaches the customers.

In short

Commit = new version (with author, time, message, parents); branch = isolated line for a change, variant or maintenance; merge/PR = joins two lines (two parents), with review as lightweight change control; tag = immutable label for a baseline or release. The typical flow: tag → feature branch → commits → PR with CI and review → merge to main → tag the new release.

10.7

Change Control and the CCB

Version control records changes; it does not decide whether a change should happen. A client asking for "one small extra field" can trigger a ripple through requirements, design, code, tests and documentation (§10.1). Change control is the gate that makes sure such a change is understood, justified and carried out properly before it touches the configuration.

Definition · change control (W09)

Change control manages changes that affect more than one CI. It is a manual step combining human procedures and automated tools, in which each change request (CR) is evaluated for its technical merit, its side effects, its impact on other CIs and on system function, and its cost. A change request is a formal, written request to change something that is under CM.

The lecture's three phases: Initiate → Evaluate → Make exam

The lecture defines each phase by the questions it has to answer. If you can recite the questions, you can write a good exam answer about any change.

Why, then whether, then how. Initiate asks why and how to judge it; Evaluate decides whether it is worth it by tracing its effects; Make asks how it gets done and communicated. The detailed procedure below fits inside these three phases.

The detailed procedure exam

Combining the slides, Pressman and the course's PMP template gives a more detailed procedure. Two rules hold throughout: anyone may raise a CR, and every CR is logged and tracked to closure, whether it is approved or not. The decision is made by the change (configuration) control board (CCB), the group with authority to approve changes, introduced properly after the stepper.

A change request from first idea to closure

The whole procedure, faded. Colours: originator (whoever asks for the change), configuration manager (keeps the register), developers, violet for the CCB, and gold for the baseline. Press Next.
A need for change is identified (a new requirement, a problem, a new device) and the originator submits a change request. Anyone may raise a CR.
The CR is logged in the change register (the list of all CRs and their status) and given an ID, so it can be tracked to closure whatever happens to it.
An impact analysis works out which CIs are affected, and the cost, schedule and risk of the change: in other words, how far the ripple goes.
The CCB decides. Per T09 it has three options: approve, approve with conditions, or delay/reject.
If the CR is rejected or deferred, the originator is told why, and the CR is closed or parked for later. It stays in the register either way.
If it is approved (perhaps with conditions), a change order is issued and the work is scheduled.
Developers branch from the baseline and change ALL the affected CIs, not just the code: design, tests, docs and release notes too.
The change is verified by review, regression testing and audit.
It is merged, a new version is tagged, and the baseline is updated to include it.
Finally, the status records are updated, stakeholders are notified and the CR is closed.

What to evaluate in a change request exam

The impact-analysis box hides a lot of thinking. The W09 slides list seven areas to evaluate, each with a key question. In an exam question about a proposed change, walking through all seven is a reliable structure.

Seven questions, one decision. Technical merit asks whether the change is worth having at all; the other six ask what it will cost to get it safely. A CCB weighs the first against the rest.

The Change (Configuration) Control Board exam

Definition · CCB

The CCB is the authority that reviews, evaluates, and approves or rejects proposed changes to baselined items. (This is the answer to the T09 multiple-choice question on the CCB's purpose.) Pressman calls it the change control authority.

Its job has several parts. It ensures that changes are justified, analysed and prioritised; it weighs each change's benefit against its cost, schedule and risk; it protects the integrity of the baseline; and it tells affected parties of its decisions.

Three possible outcomes (T09). "Approve with conditions" is the answer the tutorials reach most often: yes, but only once a named risk has been dealt with (a spike, a tested rollback, a mitigation in place).

Who sits on it

A CCB needs both technical and business views, because a change has both technical consequences and costs. The chair is someone with authority over scope, cost and schedule: the project manager (PM), or the sponsor (the senior person who funds the project) in the PMP template. The other members are a customer/user representative; the configuration manager, who acts as secretary and keeps the register; the technical lead or architect; QA/test; and representatives of affected groups, such as operations/maintenance, documentation and subcontractors. The requester should not dominate.

Chair, secretary and members. The chair can commit scope, cost and schedule; the configuration manager runs the paperwork; the rest bring the views a change has to satisfy. These role colours are used for the same people throughout this Part.

On scale: on a small project one person may be the whole CCB, while contracts between a client and a supplier often add a joint client–supplier board for changes to scope or price.

The change management plan

Complex or distributed teams rely on a written change management plan, which is part of the overall CM plan. It must let everyone find out what changes must be made, what they must do, why the change is happening and how it affects them (W09). This matters most in distributed structures, where a change may have to be negotiated between sites or companies. Following the PMP template, the plan names who submits and who approves changes (the CCB, and the cost thresholds above which a change needs higher approval) and how changes are logged.

PMBOK (the Project Management Institute's body of knowledge) draws a distinction worth knowing:

PMBOK plan	What it covers
Change management plan	How change requests are authorised and incorporated
Configuration management plan	Which items are recorded and updated to keep the product consistent

Check yourselfWhat is the purpose of a Change Control Board?

To write the code for approved changes
To keep every artefact under version control
To review, evaluate, and approve or reject proposed changes to baselined items
To compare deployed versions against the approved baseline

C, the T09 answer. A is the developers' job; B is version control; D is a configuration audit (§10.9).

Check yourselfSelect all that apply. Who should normally be on a CCB?

The PM or sponsor, as chair
The configuration manager, as secretary
The requester, as chair, since they understand the change best
A customer/user representative
Only developers, since changes are technical

A, B and D. The requester should not dominate (C), and a CCB needs business as well as technical views (E), because it weighs benefit against cost, schedule and risk.

Check yourselfA client asks to "just add a middle-name field to the sign-up form". Using the three lecture phases, say what happens in each.

Initiate: raise a CR saying why (the client's need), what information is needed and how it will be judged. Evaluate: trace the ripple (requirement, form design, database schema, validation code, tests, docs), weigh benefit against cost and risk, and identify who is affected; the CCB decides. Make: assign who does it, branch from the baseline, change all the affected CIs, verify, tag, notify everyone and confirm it is finished. Even a "small" change is logged (a pitfall the guide names).

In short

Change control manages changes that affect more than one CI. Lecture phases: Initiate → Evaluate → Make. Detailed procedure: submit → log → impact analysis → CCB decision → change order → branch and change all CIs → verify → merge, tag, rebaseline → update records, notify, close.
Evaluate seven areas: technical merit, side effects, impact, dependencies, cost, scheduling, risk.
The CCB approves, approves with conditions, or delays/rejects changes to baselined items; chaired by the PM or sponsor, with the configuration manager as secretary.

10.8

Baselines

If the requirements document can change at any moment, the designers are designing against a moving target and the testers never know what "correct" means. A baseline fixes a reference point: this version, agreed by everyone, is what we build on, and changing it is now a formal decision.

Definition · baseline (W09, after IEEE) exam

A baseline is an artefact that is stable, has been formally reviewed and agreed upon, is ready for further development, and can only be changed through a formal change management procedure.

Baselines matter for several reasons. They give the project a fixed reference point, so nobody is working against a moving target. A baseline defines what counts as a "change": anything that differs from it. And it enables rollback (as at Coles), contractual acceptance (the client signs off a specific baseline) and audits (which compare reality against it). The key behavioural difference is the moment of baselining: before it, changes to an item are informal; after it, every change goes through change control.

Before: changes are informal. That is fine for a draft that is still being worked out.

After: the item is frozen as a reference. The only door in is the change control procedure of §10.7.

A sequence of baselines

A project does not have one baseline; it sets one at the end of each major stage, each building on the last. The guide's sequence runs from requirements to release.

Gold diamonds are baselines, the same symbol as the tags in the Git diagrams. Each one says "this much is now agreed". A change to the SRS after the requirements baseline is no longer an edit: it is a change request.

The same idea runs through the rest of the subject. The scope, schedule and cost baselines in the Project Management Plan work the same way (Part V, Part VIII): once approved, they change only through change control. In Scrum, each Done increment and each tagged release acts as a baseline (Part VI).

Check yourselfSelect all that apply. Which are properties of a baseline in the W09/IEEE definition?

It is stable
It has been formally reviewed and agreed upon
It can be edited by any developer until release
It can only be changed through a formal change procedure
It must be the final release

A, B and D (plus "ready for further development", not listed). C is exactly what baselining stops. E is wrong: there are baselines at every stage, from requirements onwards.

In short

A baseline is stable, formally reviewed and agreed, ready for further development, and changeable only through formal change control. It fixes a reference point, defines what a "change" is, and enables rollback, acceptance and audit. Projects set them in sequence: requirements, design, code, test and release.

10.9

Auditing and Status Reporting

Procedures only help if they were actually followed. Two activities close the loop: auditing checks that the configuration really is consistent and correct, and status reporting keeps everyone informed about where every item stands.

Configuration auditing

Auditing assures that what is in the repository is actually consistent and that all changes were made properly (W09). A typical audit activity is comparing the deployed versions with their approved baseline; that is the answer to the T09 multiple-choice question on audits. An audit asks four questions, each with its own purpose.

Each question protects one property. The example finding fails the fourth question (an outdated item) and, through it, the second (a dependency between requirement and tests is broken).

There are two kinds of configuration audit, and they differ in what they compare the CI against.

Functional: behaviour versus requirements.

Physical: what was shipped versus what the documents say was shipped. (File names illustrative.)

Audits in general, and how to run one, are covered in Part VII.

Status reporting (status accounting)

Status reporting "provides visibility into the state of configuration items and helps teams detect inconsistencies, omissions, or delays" (W09). It tracks four elements, shown below: the status of each item, progress against baselines, alignment with the schedule, and the backlog of change requests.

Visibility, not control. Status reporting changes nothing by itself; it makes problems visible early. The configuration manager usually produces these outputs from the register and the repository.

Status reporting matters because it detects missing or outdated artefacts, spots configuration drift early (drift is when items gradually move away from their baseline, or away from each other, without anyone deciding they should), keeps development and CM progress aligned, and informs decisions. Its outputs are the CR register, CI status lists, and a version description document (VDD), which records what each release contains.

Check yourselfWhich of these is a typical configuration audit activity?

Approving a change request
Comparing the deployed versions with their approved baseline
Creating a feature branch
Estimating the cost of a change

B, the T09 answer. A is the CCB's job, C is version control, and D is part of impact analysis in change control.

Check yourselfAn auditor checks that the installer delivered to a hospital contains exactly the files and versions listed in the version description document. Functional or physical audit?

Physical. It asks whether the CI is built as documented: delivered items and versions match the VDD and design docs. A functional audit would instead check, through test results and traceability, that the product does what its requirements specify.

In short

Auditing checks the repository is consistent and changes were made properly: all CIs versioned (traceability), dependencies consistent, approved changes applied (integrity), nothing missing or outdated (completeness). Functional audit: does it do what is required? Physical audit: is it built as documented?
Status reporting tracks item status, baseline progress, schedule alignment and the change backlog; its outputs are the CR register, CI status lists and the VDD.

10.10

CI/CD and CM in Agile Teams

An agile team may change its code dozens of times a day. Doing identification, building, testing, auditing and tagging by hand at that pace is impossible, so modern teams automate it. That automation is CI/CD, and it is CM carried out by a machine.

Continuous integration

Definition · continuous integration (CI) (Atlassian)

"Routinely integrating code changes into the main branch of a repository, and testing the changes, as early and often as possible", ideally daily or more often.

CI pairs continuous builds, ideally with one change-set per build (so a failure points straight at the change that caused it), with test automation. Each run first checks that the code compiles, and then that it works as designed. The payoff is that feedback arrives "within minutes", not days. That takes discipline: fix a broken build immediately, because while main is broken nobody else can integrate safely.

Small changes, fast verdicts. Because each build holds one change-set, a red build points straight at its cause, and the developer still remembers what they just did.

The automated tests come in layers that trade speed for realism. Unit tests check one small piece in isolation; they are fast but miss whole workflows. API tests cover the interfaces between modules. Functional/UI tests mimic users clicking through the system, which makes them slower and sometimes flaky (passing or failing at random, for reasons unrelated to the change).

Layers of automated tests. The lower layers run on every commit because they are fast; the top layer catches what only a whole workflow reveals.

CI vs continuous delivery vs continuous deployment exam

Three terms with similar names, and the exam likes to test the difference. Continuous delivery extends CI with an automated pipeline that keeps every change releasable; continuous deployment goes one step further and actually releases every change that passes. The row to notice is the human gate.

The difference is who presses "release". In continuous delivery a person may decide when a ready change goes live (for example a business release decision); in continuous deployment, passing the tests is the decision.

	CI	Continuous delivery	Continuous deployment
What	Frequent merges to main with automated build and tests	An automated pipeline keeps every change releasable (test → staging → production-ready)	Every change that passes the automated tests goes to production automatically
When (Synopsys)	While code is being written	After code is complete	After code is complete
Human gate	None	Manual gate before production allowed (e.g. a business release decision)	None
Fit	All teams	Regulated or safety domains; business-timed releases	Teams not constrained by regulation

The pipeline in four phases

Atlassian describes the pipeline in four phases, each running its own tests. Testing in every phase like this is called continuous testing. The benefits are velocity (faster delivery), productivity and sustainability. CI/CD is part of DevOps (development and operations working as one team with shared automation), and DevSecOps builds security testing into the pipeline as well.

Tests widen as the change travels. A smoke test is a quick check that the deployed system starts and its main functions respond at all.

A pipeline is automated CM

Each CM activity has a counterpart in the pipeline. A commit triggers a build that reproduces the derived CIs from controlled sources; the tests verify the change; every run leaves an audit trail of what was built, from what, and with what result; and releases are tagged. At Knight Capital, automated deployment to all servers, plus a version check, would have prevented the failure.

CM in agile teams

In agile teams, CM is lightweight and automated, built on Git, pull-request review, CI/CD and tags. The Product Owner (the Scrum role accountable for the product's value and for ordering the Product Backlog; Part III) is the de facto change authority: change requests enter the Product Backlog and are prioritised there. In the W09 scenario, for instance, the change was "accepted by product owner". Changes in the middle of a sprint are negotiated so as to protect the Sprint Goal (the single objective the team commits to for the sprint). The Definition of Done (DoD), the checklist every item must meet to count as finished, can also include CM conditions.

Same functions, lighter machinery. The Product Owner plays the CCB's role through backlog ordering, the DoD enforces the CM checks, and CI/CD does the building, verifying and tagging.

Pitfall: "agile means no CM"

Thinking that agile means "no CM" is the classic mistake. Frequent change actually needs more version control and automation, not less: the more often things change, the more you need to know exactly what changed and to be able to roll it back.

A formal CCB is still needed for contractual, regulated or safety-critical work, and for cross-team changes (scaled agile, Part XI).

Check yourselfA bank's mobile app must be signed off by a compliance officer before each release. Which practice fits: continuous delivery or continuous deployment?

Continuous delivery. It keeps every change releasable but allows a manual gate before production, exactly where the compliance sign-off sits. Continuous deployment has no human gate, which suits teams not constrained by regulation.

Check yourselfSelect all that apply. In an agile team, which of these carry out CM functions?

The Product Owner ordering change requests in the Product Backlog
A DoD item "version tagged and CI green"
Skipping the CR log for small changes to stay agile
Pull-request review before merging

A, B and D. The PO is the de facto change authority, the DoD enforces CM checks, and PR review is lightweight change control. C is a named pitfall: don't skip the CR log for "small" changes.

In short

CI = frequent merges to main with automated build and tests; fix a broken build immediately. Continuous delivery keeps every change releasable and allows a manual gate; continuous deployment releases every passing change with no gate.
A pipeline is automated CM: build reproduces derived CIs, tests verify, runs leave an audit trail, releases are tagged.
In agile, CM is lightweight and automated; the PO is the change authority via the backlog, the DoD holds CM checks, and a formal CCB remains for contractual, regulated, safety-critical or cross-team changes.

10.11

Worked Exercise: Student Enrollment exam

The W09 lecture ties every activity together in one exercise, and the guide marks it as examinable. It is the template for any "apply CM to this change" question: take the five activities in order and apply each one to the scenario.

The scenario

A university's Student Enrollment System is at release v1.2. The change request is: "Add support for international student numbers (IDs)." Five CIs are involved: StudentAPI.java (code), API_Design_Diagram.vsdx (design), Requirement R-203, EnrollmentTest.java (test script) and ReleaseNotes_v1.2.md (documentation).

The five CM activities applied to one change request

The change request and its five CIs. Before touching any code, work through the five activities in order.
1 · Identification. All five CIs are relevant, and they form a chain: R-203 → design diagram → code → test → release notes. You should also check unlisted items, such as the database schema, which must store the new ID format.
2 · Version control. The current version is v1.2, as the release notes show. Tag v1.2 and branch from it before changing anything, so v1.2 stays available as a rollback baseline. The outcome is v1.3 if the change is backward compatible (a MINOR bump), but v2.0 if the existing ID format or API contract breaks (a MAJOR bump).
3 · Change control. The team lead wants answers on technical merit (is the need real?), impact (on the API design and database schema), side effects (enrolment regressions), dependencies (who relies on the current ID format?), cost (development, testing and docs), scheduling (this sprint or release?) and risk (the likelihood and consequences of failure). These are the seven areas of §10.7.
4 · Audit. The audit checks whether the new code is committed with a v1.3 tag; whether the design, test and code match the updated R-203; whether the test plan reflects the change and the CR process was followed; whether the release notes still say v1.2; and whether EnrollmentTest.java was overlooked. The red question marks flag the two CIs most likely to be left behind.
5 · Status report. At the end of the sprint, each CI has a status, shown by the chips and in the table below. Note how the documentation waits for everything else.

An illustrative status report at the end of the sprint looks like this:

CI	Status	Note
Requirement R-203	Approved	Accepted by the product owner
API_Design_Diagram	Drafted	Pending review
StudentAPI.java	In progress	On a feature branch
EnrollmentTest.java	Not started	Needs international-ID cases
ReleaseNotes_v1.3.md	Not started	Waits for the other changes to finish

Notice that R-203 was "accepted by the product owner": this is the agile pattern of §10.10, where the Product Owner acts as the change authority.

Check yourselfWhy must the team tag v1.2 before creating the branch, rather than after the change is done?

Tagging first fixes v1.2 as an immutable rollback baseline: whatever happens on the branch, the exact released version can be rebuilt and redeployed (the Coles lesson). Tag it afterwards and you may be labelling something that already includes part of the change.

Check yourselfThe new IDs are longer, and existing API clients that validate the old 8-digit format will now reject some responses. Is the result v1.3 or v2.0?

v2.0. The change breaks the existing ID format / API contract for current clients, so it is a breaking change and MAJOR goes up (lower fields reset). Had old clients kept working unchanged, it would be a backward-compatible feature: v1.3.

In short

Apply the five activities in order. Identify all affected CIs and their chain (plus unlisted ones like the DB schema); version: tag v1.2 and branch first, then v1.3 or v2.0; change control: the seven evaluation areas; audit: tags, consistency with R-203, the test plan, stale release notes, overlooked tests; status report: each CI's state.

10.12

Applying It to the Medic Case

The Medic case in brief

Medic is the tutorials' running case. A team of 12 developers and 2 managers is building a virtual-reality surgical simulator for the eye-and-ear hospital RVEEH, so that surgeons can practise cochlear-implant and temporal-bone surgery without the scarce cadavers they use now. Two client surgeons define what it must do. The trainee sees the bone in stereoscopic 3D and feels it through haptic devices (hand-held controllers that push back with force), so it has strict performance and reliability requirements. C++, stereoscopic 3D and haptics are all new to the team. When it is finished, RVEEH IT takes it over and must keep it working through their hardware and operating-system upgrades.

Its scope is seven features: load model; stereoscopic rendering; 3D and microscope viewing; select procedure and configure haptics; perform procedure; save and restore; and replay and pause.

Medic's configuration items

The Medic project has CIs of all three types from §10.3.

Note the "less obvious" CIs. Force-model parameters, device configuration and SDK versions change the simulator's behaviour as surely as code does, so they are tracked too. The derived CIs are rebuilt, so their inputs must be controlled.

Medic's baselines

The project's baselines fall at four points, with the third repeated once per increment (an increment is a working slice of the product delivered in one stage).

Four kinds of baseline, six in all. Each gold diamond marks a point after which changes need a CR. The architecture baseline matters most here: the language choice is negotiable now, but once baselined, switching away from C++ would be a major change request.

A change request walk-through: RVEEH replaces its haptic devices

Midway through, RVEEH decides to replace its haptic devices. This is exactly the kind of change CM exists for: it touches code, configuration, tests and the manual, and it threatens the strict performance requirements. The CR goes through the change-control phases of §10.7.

CR-021: new haptic devices, from request to release

The simulator is running at the R2 baseline (the release with select/perform procedure). RVEEH now decides to replace its haptic devices.
Initiate. The RVEEH IT representative raises CR-021, giving the reason (the old devices are unsupported) and the affected CIs.
Evaluate. The evaluation covers the side effects on force rendering and on the "configure haptic IO" feature, the risk to the strict performance criteria, the dependency on the new SDK (the device maker's software library), and the cost and schedule, given the team's weak haptics experience.
CCB. The board is the surgeons, the management team, the dev lead, the QA lead, RVEEH IT and the configuration manager. Its decision: approve with conditions.
The conditions: a timing spike must come first (a short experiment to measure whether the new devices can meet the timing/performance needs), and the old device is kept as a variant (v1.3-DeviceA / v1.3-DeviceB) until trials pass. Same features, different hardware: a textbook variant.
Make. The team branches from the R2 baseline and updates all the affected CIs: code, config, tests and the manual.
It runs regression and performance tests and audits the result.
It tags v1.3 (in two variants, one per device) and notifies the surgeons and IT. The CR can now be closed.

Which CI/CD practice suits Medic? Medic is a medical system run by hospital IT, so continuous delivery with a manual release gate fits it better than continuous deployment: every change is kept releasable, but a person (with the CCB's approval) decides when a new version reaches the hospital.

Check yourselfIn CR-021, why is "v1.3-DeviceA / v1.3-DeviceB" a pair of variants rather than two versions?

Both offer the same functionality; they differ only in a non-functional aspect, the hardware platform (which haptic device is driven). Functionally identical but differing in setup is the definition of a variant. A version would mean a functional change.

Check yourselfClassify these Medic CIs as basic, aggregate or derived: (a) the installer given to RVEEH IT; (b) the force-model parameters; (c) the Haptics module.

(a) Derived: generated by the build. (b) Basic: a single item made by people. (c) Aggregate: code, tests, device config and design managed as one unit.

In short

Medic has basic CIs (feature list, C++ source, bone models, force parameters, device config and SDK versions, tests, manual, build scripts), an aggregate (the Haptics module) and derived CIs (executable, installer). Its baselines: requirements, architecture, one release per increment, operational. CR-021 runs Initiate → Evaluate → CCB (approve with conditions: spike first, keep the old device as a variant) → Make (branch from R2, update all CIs, test, audit, tag v1.3, notify). Continuous delivery with a manual gate suits it.

10.13

The Knight Capital Tutorial (T09)

Tutorial T09 takes the Knight Capital failure of §10.2 and asks what CM should have done. Its multiple-choice answers are B, C, B, which are the three answers given earlier on this page: CIs are the artefacts tracked under version control (§10.3); the CCB reviews, evaluates, and approves or rejects changes to baselined items (§10.7); and a typical audit compares deployed versions with the approved baseline (§10.9).

Task 1: which CIs to track, and which to exclude

The skill being tested is judgement: a CI is worth tracking if this change could make it inconsistent, and not otherwise.

The deployment script is the surprise. Students tend to track only the code. But deploy.sh decides whether all eight servers end up identical, and that is exactly where Knight Capital failed; the config file is equally dangerous.

Task 2: risks and mitigations, then a decision

Each mitigation answers one of the four failures. Automated, verified deployment fixes "no coordinated deployment" and "no consistency check"; a rehearsed rollback fixes "no rollback plan"; auditing every server against the baseline fixes "no audit". A kill switch is a way to stop the system immediately if it misbehaves.

Check yourselfWhy is RoutingConfig.yaml tracked as a CI even though it contains no code?

Because it controls runtime behaviour, so it is as risky as code: a wrong or stale setting changes what the system does. Runtime configuration files are one of the "less obvious" CIs (§10.3), and reusing an old config flag is one of the environment-consistency risks.

In short

Track the routing code, deploy.sh, the config file, the test suite and UML diagram, and the release note; exclude the strategy document, UI mockups and README. Mitigate deployment (automate and verify every server), rollback (rehearse; kill switch) and environment consistency (delete dead code, no reused flags, audit servers). Decision: approve with conditions, otherwise delay.

10.14

Pitfalls and Self-Test

This last section gathers the mistakes that most often cost marks, then works through every self-test question in the guide. Questions tagged with a year are real questions from predecessor subjects' exams (433-443), not SWEN90016 papers; the answers are the guide's model answers, not official ones.

Pitfalls

Don't update the code without also updating the CIs that depend on it (design, tests, docs, release notes).
Don't confuse a version, which is a functional change, with a variant, which has the same features in a different setup.
Don't assume that version numbers show derivation: V2.0 can come from V1.1a, not V1.2.
Don't skip the CR log for "small" changes.
Don't think agile means "no CM": frequent change needs more version control and automation, not less.

How CM is examined

Expect MCQs on the definitions (CI, CCB, baseline, audit, version vs variant vs release, CI vs delivery vs deployment) and written questions that hand you a change and ask you to apply CM to it. For those, walk the five activities in order, as in the Student Enrollment exercise, use the seven evaluation areas for the change-control part, and end with a CCB decision (often "approve with conditions") justified against the case facts.

Questions from predecessor exams

Past exam · 433-443 1998 Q7Describe the steps of the change control procedure. What is the role of the Configuration Control Board, and who should be a member?

The change control procedure has nine steps (the stepper in §10.7 draws them):

The originator submits a change request (CR).
It is logged and given an ID.
An impact analysis assesses the affected CIs, cost, schedule, risk and benefit.
The CCB approves, rejects or defers the CR, and the originator is told the outcome.
If the CR is approved, a change order is scheduled.
The affected CIs are branched from the baseline and changed.
The change is verified by review, regression test and audit.
It is checked in, a new version is tagged and the baseline is updated.
Status records are updated, stakeholders are notified and the CR is closed.

CCB role: the CCB is the authority for changes to baselines. It judges each change's justification, cost/benefit and risk, prioritises changes, protects the integrity of the baseline and communicates its decisions.

Members: the PM or sponsor (as chair), a customer/user representative, the configuration manager (as secretary), the technical lead, QA/test, and representatives of affected groups.

Past exam · 433-443 1999 Q18Innovative Pty Ltd (the supplier) is building a payroll system for BigWig Ltd (the customer). Design the change request component of the project's change control: the forms and the procedure.

Forms. The component needs three forms.

The Change Request Form records the CR number, title and date; the originator's name, position and organisation; the affected requirement/CI and baseline version; a description; the reason and benefit; the priority; the type (change or suspected defect); BigWig's authorisation signature; and Innovative's receipt, status and disposition fields.
The Change Request Register records each CR's number, title, originator, dates, status (Received / Under review / Accepted for proposal / Rejected / Closed) and owner.
An acknowledgement/disposition notice.

Steps. The procedure runs in five steps across the two companies:

One door in, one register. All of BigWig's requests pass through its PM, and Innovative's configuration manager keeps the single register, so neither side can lose or bypass a CR. (Colours: customer, supplier.)

The BigWig originator (for example a payroll officer) completes the form.
The BigWig Project Manager, who is the sole authorised customer contact, checks that it is valid, not a duplicate and not really a defect, and then either signs and sends it or returns it to the originator.
The Innovative Configuration Manager registers it, assigns a number, sets its status to "Received" and acknowledges it to the BigWig PM within an agreed time.
The Innovative Project Manager and technical lead screen it, clarifying it with the BigWig PM. They then either accept it into the change-proposal component (a costed impact analysis and joint approval) or reject it with reasons.
The Configuration Manager updates the register and sends status reports to both PMs. Any disputes go to a joint CCB.

Past exam · 433-443 1999 Q13Audit a project against its documentation procedure (the CM angle).

Start by requesting the document list (SPMP, SRS, SDD, STD, UM, VDD: the project management plan, requirements spec, design description, test documentation, user manual and version description document) and the version-control listing. Then check each document against the procedure:

Does it have a document number, and is it under version control?
Did its drafts start at 0.1?
After review, is the issue set to N, is the VCS state REVIEWED, and are the review form and mark-up filed?
Is the issued copy stamped "controlled" with a copy number, and does it match the VCS version?
Did the PM apply the procedure?

Record objective evidence for each check. (Audits are covered in depth in Part VII.)

Past exam · 433-443 2001 Q3Besides evaluation and control of change, describe the other two functions of SCM.

Configuration identification means selecting the CIs, giving them unique names and versions, recording their relationships, and establishing baselines.

Configuration status accounting means recording and reporting the status of CIs, baselines and CRs (what changed, who changed it, when, and what is pending), which gives visibility and traceability.

(IEEE 828 adds a fourth function, audit.)

Past exam · 433-443 2001 Q4Discrepancy reports vs change requests: how and why are they handled differently?

The baseline decides. Failing the agreed baseline is the supplier's problem; changing the baseline is a joint decision with a price.

Definitions. A discrepancy (defect) report says the product does not conform to its approved baseline, whereas a change request asks to change the baseline.
Handling DRs. A DR is fixed within scope at the supplier's cost. The team triages it by severity, fixes it, retests it and closes it, with no scope approval.
Handling CRs. A CR alters scope, cost and schedule, so it needs an impact analysis, CCB/customer approval, and possibly a contract variation and price.
Why. The cost and risk belong to different parties, the contractual impact differs, and the two feed different metrics. Mixing them either hides scope creep as "bug fixes" or bills the customer for defects.
Conversion. If the specification itself is wrong, the DR becomes a CR.

The guide's other self-test questions

Self-test 6Define a baseline, with one example per phase.

A baseline is a stable, formally reviewed and agreed artefact that is the basis for further work and can be changed only via formal change control. Examples, one per phase: an approved SRS, an approved design, reviewed code, an approved test plan, and a tagged release v1.2.

Self-test 7Distinguish version, variant and release.

A version is functionally different, as when v1.1 adds login. A variant has the same functions with a different platform or language, such as Windows and Mac variants. A release is a version or variant formally delivered outside the team, and it is usually baselined (App Store v3.1.2, for example).

Self-test 8Classify: Login.java, build.zip, "Payments module = code + tests + design", Requirement R-101.

Login.java is basic, build.zip is derived, the Payments module is aggregate, and Requirement R-101 is basic.

Self-test 9In the W09 derivation diagram, what is V2.0 derived from, and what does it show?

V2.0 is derived from V1.1a, not V1.2 (V2.2 is the one that comes from V1.2). This shows that derivation is a graph, so version numbers don't reveal ancestry, and the version-control system must record it.

Self-test 10The current version is 2.4.7. Apply a bug fix, then a backward-compatible feature, then a breaking API change.

2.4.7  --bug fix (PATCH+1)----------------------->  2.4.8
2.4.8  --compatible feature (MINOR+1, PATCH=0)--->  2.5.0
2.5.0  --breaking API change (MAJOR+1, rest=0)--->  3.0.0

Self-test 11 · lecture scenarioA week after Student Enrollment v1.3 ships, an audit finds EnrollmentTest.java unchanged and the release notes still saying v1.2. What failed, and what now?

What failed: only the code was changed. The dependent CIs were not identified, and verification and audit were skipped before baselining.

What now: raise a CR or defect report, add international-ID tests and regression-test v1.3, fix the release notes, and re-audit, tagging v1.3.1 if the code changes. Then add "tests and release notes updated" to the DoD or the CR checklist, so it cannot happen again.

Self-test 12Coles 2020: what failed, what saved them, and what would have prevented it?

Failed: there was no cross-environment regression testing, no rollback documentation and no coordination with the dependent payment systems. Saved: a stored, traceable previous version meant they could roll back to the baseline (about 4 h). Prevention: an impact analysis of dependencies, a staged rollout, a tested rollback plan and automated regression tests.

Self-test 13CI vs continuous delivery vs continuous deployment: which suits Medic?

CI means frequent merges with automated build and tests. Continuous delivery keeps every change production-ready, with a manual release gate allowed. Continuous deployment sends every passing change live automatically. Medic is a medical system run by hospital IT, so it suits continuous delivery with a CCB-approved release gate.

Self-test 14"We're a Scrum team, so we don't need configuration management." Discuss.

The claim is false. Frequent change raises the need for version control, CI/CD and tagged increments as baselines. In Scrum, the Product Owner is the change authority via the backlog, and the DoD enforces CM checks. And contractual, regulated or cross-team changes still need a formal CCB.

In short

Change every dependent CI, keep versions and variants apart, never read ancestry from version numbers, and log even small changes.
For any "apply CM" question: identification → version control → change control (seven areas, CCB decision) → audit → status report, tied to the case facts.