CHANGE CONTROL combines HUMAN PROCEDURES and AUTOMATED TOOLS to provide a mechanism for the control of change. It is necessary because uncontrolled change rapidly leads to chaos on a project of any size — but too much change control creates its own problems, and the balance is a real judgement. THE PROCESS, step by step (Pressman): 1. A CHANGE REQUEST (CR) is submitted and evaluated to assess technical merit, potential side effects, overall impact on other configuration objects and system functions, and the projected cost of the change. 2. The results of the evaluation are presented as a CHANGE REPORT, which is used by a CHANGE CONTROL AUTHORITY (CCA) — a person or group who makes the final decision on the status and priority of the change. 3. An ENGINEERING CHANGE ORDER (ECO) is generated for each approved change. The ECO describes the change to be made, the constraints that must be respected, and the criteria for review and audit. 4. The object to be changed is CHECKED OUT of the project database, subject to access control and synchronisation control. 5. The change is made and appropriate SQA activities are applied. 6. The object is CHECKED IN to the database and appropriate version control mechanisms are used to create the next version of the software. ACCESS CONTROL AND SYNCHRONISATION CONTROL — the two mechanisms that make check-out/check-in work: ACCESS CONTROL governs WHICH software engineers have the authority to access and modify a particular configuration object SYNCHRONISATION ensures that parallel changes made by CONTROL two different people do not overwrite one another THE CHANGE CONTROL AUTHORITY / CHANGE CONTROL BOARD (CCB) reviews change requests and decides. Its composition matters: it must include people who understand the technical impact AND people who own the business priority, because a change decision requires both. A CCB of only engineers approves technically interesting changes; a CCB of only managers approves changes whose cost nobody has assessed. BEFORE AND AFTER AN SCI IS BASELINED — the crucial distinction: BEFORE a software configuration item becomes a baseline, only INFORMAL change control need be applied. The developer may make whatever changes are justified by project and technical requirements, as long as the change does not affect broader system requirements outside the developer's scope of work. AFTER the object has undergone formal technical review and been APPROVED, a baseline is created, and a formal change request with impact evaluation and CCA approval is required. → the ceremony is proportional to who else is affected, which is the principle behind the whole procedure.

WHAT AN EVALUATION SHOULD CONTAIN. Take a real-shaped request. ───────────────────────────────────────────────────────────── CR-227 "Allow an officer to reverse an ISSUED licence within 24 hours of issuance." RAISED BY district office supervisor DATE 2026-03-14 ───────────────────────────────────────────────────────────── TECHNICAL MERIT Legitimate: officers currently correct mistakes by raising a manual ticket, averaging 3 days. 40–60 such corrections per month. IMPACT ANALYSIS, using the traceability matrix: requirements affected R-051 legal status transitions → ISSUED is currently TERMINAL. This is a change to the state machine. R-072 audit trail → a reversal must be recorded, with the reason and the officer R-088 licence number allocation → CRITICAL: is the number released for reuse, or permanently retired? R-091 revenue reporting → a reversed licence must not count as revenue R-102 police notification → the police system was already told the licence was issued; it must be told of the reversal design affected StatusTransitionService, AuditWriter, LicenceNumberPool, RevenueReport, PoliceGateway — 5 modules interfaces affected the POST status endpoint gains a new transition and a new 409 case; the police notification interface needs a reversal message THAT DOES NOT CURRENTLY EXIST — an external dependency, so another organisation must agree tests affected 31 test cases assume ISSUED is terminal data affected no schema change, but existing ISSUED rows have no reversal window recorded, so the 24-hour rule needs an issuance timestamp — which exists SIDE EFFECTS AND RISKS — the part naive evaluations omit: · SECURITY: reversal is a privilege that can hide fraud. It needs its own authorisation and a non-repudiable audit record. This CR creates an attack surface. · the LICENCE NUMBER question (R-088) is unresolved and is a REQUIREMENTS question, not a technical one — the CCA cannot approve until the business answers it. Reusing a number would break the reprint guarantee discovered in the elicitation topic. · the POLICE INTERFACE requires agreement from an external organisation, so the schedule is not under our control. This is the inter-organisational dependency problem. COST ESTIMATE requirements amendment + review 8 h design 12 h implementation (5 modules) 46 h external interface negotiation unknown — 2 weeks elapsed, ~6 h effort test updates (31 cases + new) 28 h security review 6 h regression + UAT 20 h ───────────────────────────────────────────── ≈ 126 person-hours ≈ 16 person-days, plus an externally-gated 2-week wait CCA DECISION — and note that the honest decision is not yes or no: DEFERRED pending two answers: (a) business ruling on licence-number reuse (R-088) (b) written confirmation that the police system will accept a reversal message In the meantime, an INTERIM measure is approved: reduce the manual correction turnaround from 3 days to 1 by giving supervisors direct access to the existing ticket queue — 2 person-days, delivering most of the benefit at 1/8 the cost. THE LESSON: THE MOST VALUABLE OUTPUT OF CHANGE EVALUATION IS OFTEN NOT THE CHANGE. Two open questions were surfaced that would have caused a production incident, and a cheaper alternative was found. A CCB that only says yes or no is doing half the job.

TOO LITTLE CHANGE CONTROL AND TOO MUCH ARE BOTH REAL FAILURES, with recognisable symptoms. SYMPTOMS OF TOO LITTLE: · nobody can say why a line of code exists · defects reappear after being fixed · two people fix the same thing differently · a release contains changes nobody intended to ship · production diverges from the repository SYMPTOMS OF TOO MUCH: · a one-character typo fix takes three weeks and four signatures · developers batch changes to avoid the process, producing large risky changes instead of small safe ones — WHICH IS THE OPPOSITE OF THE INTENDED EFFECT · the CCB becomes a rubber stamp because it has no time to evaluate properly · people route around the process for urgent work, and the route-around becomes normal THE KEY INSIGHT, and it is counter-intuitive: HEAVY CHANGE CONTROL CAN INCREASE RISK. If each change is expensive to process, engineers bundle twenty changes into one submission. A large change is harder to review, harder to test, and harder to roll back — recall from the reviews topic that defect-detection rate collapses with diff size. The process intended to reduce risk has increased it. THE MODERN RESOLUTION — differentiate by risk, not by uniformity: STANDARD CHANGE pre-approved, low risk, well understood; proceeds with peer review and automated checks only. Most changes should be here. NORMAL CHANGE requires evaluation and approval proportional to impact. EMERGENCY CHANGE an expedited path with reduced pre-approval and MANDATORY post-implementation review within a fixed window. Classifying changes is what allows control to be strict where it matters and invisible where it does not. VERSION CONTROL MECHANISMS that implement change control in practice: CHECK-OUT / CHECK-IN with locking — the pessimistic model. One writer at a time. Safe, but serialises work and blocks on absent colleagues. OPTIMISTIC / MERGE model — anyone may edit; conflicts are detected and merged at check-in. This is what modern systems do, and it works because most concurrent edits do not overlap. BRANCHING AND MERGING — parallel lines of development. A RELEASE BRANCH allows a fix to be made to a shipped version without carrying unrelated new development — which is precisely the problem the no-CM incident in the planning topic could not solve. CHERRY-PICKING — applying one specific change to another branch, which is how a fix reaches both the release and the mainline. THE MERGE-CONFLICT MATHEMATICS, briefly: conflicts arise from concurrent edits to the same region. The probability rises with branch lifetime and with how many files a change touches, which is why long-lived branches are painful and why small, short-lived changes are the practical recommendation. This is the same conclusion the review-size evidence reached, arrived at from a different direction. STATUS ACCOUNTING AND AUDITING — the last two SCM tasks, which close the loop: CONFIGURATION AUDIT complements the formal technical review by assessing the configuration object for characteristics generally not considered during review. It asks: · has the change specified in the ECO been made, and have any additional modifications been incorporated? · has a formal technical review been conducted to assess technical correctness? · has the software process been followed and have software engineering standards been properly applied? · has the change been HIGHLIGHTED in the SCI, and have the change date and author been specified? Do the attributes of the configuration object reflect the change? · have SCM procedures for noting the change, recording it and reporting it been followed? · have all related SCIs been properly updated? NOTE THE SECOND QUESTION: "have any ADDITIONAL modifications been incorporated?" — the audit checks for changes that were NOT approved, which is the thing no review looks for. STATUS REPORTING (status accounting) is an SCM task that answers: what happened, who did it, when did it happen, and what else will be affected? Its output is a report distributed to developers and to management. Its purpose is to stop the characteristic failure of poor communication — two people fixing the same defect with different results.