Tracking Control Items and Procedures in Configuration

UPI Study › Courses › Software Engineering › Free lessons › Lesson 14.6 Free with a free account

Tracking Control Items and Procedures in Configuration

Software Engineering · Chapter 14: Project Estimation, Configuration, and Change ControlSection 14.6 · lesson 91 of 1037 min · free with a free account

← Configuration Management Tools: Version Control, Build Systems, and CI/CD PipelinesNext lesson: Handling Change in Projects: Planning and Key Components →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Deciding what needs control - and fixing points in time you can reconstruct.

  • Define a configuration item, and what qualifies as one
  • Explain baselines as fixed reference points
  • Describe the lifecycle states a configuration item moves through
  • Describe practical procedures for tracking items and versions

Transcript

Everything said in the video, section by section (968 words). Read along, or search it.

Project Estimation, Configuration, and Change Control

Tracking Control Items and Procedures in Configuration

Tracking code is not enough. This section covers how to decide which other work products need the same discipline, and how to fix points in time that can be reliably reconstructed later.

Which Version Shipped?

3 Weeks After a Bug Fix

A team ships a bug fix. Three weeks later, a customer asks exactly which version of the requirements, design, and test plan matched what was delivered. Nobody can say for certain. The requirements document has been updated four times since. The design was tweaked informally, in two chat messages that were never merged back into it. And the test plan used at the time cannot be told apart from later versions. The code that shipped is knowable. Everything around it, that should have moved with it, was not tracked the same way.

Configuration Items

What Qualifies?

A configuration item is any work product placed under formal configuration control. It is placed there because an uncontrolled change to it could create inconsistency, confusion, or risk elsewhere in the project. It is not only source code. Common configuration items include requirements, design documents, test plans, user documentation, and build or deployment scripts. The deciding question is simple. Does something else, like another item, another team, or an external party, depend on this work product staying stable? If a silent change to it would cause them a problem, it qualifies.

Table 1

CI or Not?

Here is how that question plays out. A requirements document is a configuration item, because design, code, and tests all depend on it. A source code module is too, because other modules and the build depend on its interface. And a test plan must stay traceable to the requirements it verifies. But a developer's scratch notes are not. Nothing else depends on them staying stable. And neither is an abandoned, unused draft, because nothing is built on top of it.

Baselines

Fixing a Point in Time

A baseline is a specific, formally reviewed and agreed version of one or more configuration items, at a point in time. It serves as a stable reference for further work, and it can only be changed through formal change control, never a silent edit. Baselines are commonly named for the milestone they fix. A requirements baseline fixes what the system must do, before design begins. A design baseline fixes how it will be built, before construction begins. And a release baseline names exactly what was delivered, across every configuration item involved.

Figure 3

The Lifecycle of a Configuration Item

A configuration item typically moves through a small set of states. It begins as a draft, while it is being created or actively edited. It is then submitted for review. If the review does not approve it, it goes back to draft for revision. Once approved, it becomes baselined. It is fixed, and now subject to formal change control. Eventually a newer baselined version may replace it. It then becomes superseded, though it stays retrievable for history.

Table 3

Still Changing, or a Fixed Reference?

Tracking the state answers a question anyone looking at an item needs answered. Is this still evolving freely, or is it a fixed, dependable reference to build on? A draft is still changing freely. An item under review cannot change without going back to draft. A baselined item changes only through formal change control. And a superseded item does not change at all, but it can still be retrieved.

Table 4

Tracking That Doesn't Rely on Memory

A few practical mechanics make this tracking workable, rather than dependent on memory. Every item gets a unique identifier, which stays stable across all of its versions. Every distinct revision gets its own version identifier, so a specific past state can always be named precisely, and retrieved. A registry lists every configuration item, with its current version, its lifecycle state, and where it can be found. And traceability links connect related items to each other, such as a design document back to the requirement it satisfies.

Worked Example

Release Baseline v1.0

Now return to the opening scenario, tracked properly. The project tracks four configuration items. Its requirements document, its design document, an authentication module, and its test plan, each with its own identifier and version. Release baseline version one point zero names exactly what shipped together. The requirements at version two point one, the design at one point three, the authentication module at three point zero, and the test plan at one point two. The customer's question is no longer a reconstruction exercise. It is a lookup, no matter how many revisions have happened since.

Apply It

Everything Is a CI

Let's apply that. A team declares every single file a formal configuration item, including personal scratch notes, and a draft nobody uses. Even trivial edits now need baseline approval and change control. Progress slows to a crawl, and the team starts quietly bypassing the process. What went wrong? Control was applied to everything, ignoring the question that should decide what qualifies. Overhead on files that nothing depends on protects nothing. And a process people bypass is worse than not controlling those files at all.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A configuration item is any work product placed under formal configuration control, because other things depend on it staying stable. A baseline is a formally reviewed version of one or more configuration items, fixed at a point in time as a stable reference. The item lifecycle is its sequence of states. Draft, under review, baselined, and superseded. A version identifier names one specific, retrievable revision. And a registry lists every item, its current version, and its lifecycle state.

Key Takeaways

What to Carry Forward

To pull this together. A configuration item is any work product that other things depend on staying stable. Not every artifact needs that level of control. A baseline fixes agreed versions at a point in time, and changing anything inside it requires formal change control. An item's lifecycle state tells a reader whether it is still evolving, or a fixed reference. Identifiers, a registry, and traceability links make tracking workable in practice. And a release baseline turns the question of what exactly was delivered into a simple lookup.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Tracking Control Items and Procedures in Configuration

What is a configuration item in software configuration management?
A configuration item is any work product placed under formal configuration control because an uncontrolled change to it could create inconsistency, confusion, or risk elsewhere. It is not only source code. Requirements, design documents, test plans, user documentation, and build or deployment scripts are common configuration items. Each gets a unique identifier that stays stable across all of its versions.
How do you decide whether something should be a configuration item?
Ask whether another item, team, or external party depends on the work product staying stable; if a silent change would cause them a problem, it qualifies. A requirements document qualifies because design, code, and tests depend on it, while a developer's scratch notes do not. Controlling every file is a common mistake that adds overhead, slows progress, and tempts teams to bypass the process.
What lifecycle states does a configuration item go through?
A configuration item typically moves from draft to under review to baselined, and later to superseded. A draft changes freely. An item under review must return to draft to be revised. A baselined item changes only through formal change control. A superseded item has been replaced by a newer baselined version but stays retrievable for history.
What are requirements, design, and release baselines?
They are baselines named for the milestones they fix. A requirements baseline fixes what the system must do before design begins, a design baseline fixes how it will be built before construction begins, and a release baseline names exactly which version of every configuration item was delivered. A release baseline turns the question of what shipped into a simple lookup.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →