In the Software Configuration Management Process: Configuration is controlled by a systematic approach named as Configuration Control.

Configuration Control Enforces a rigorous change control mechanism.

Configuration Control requires formal procedure to

  1. Request Changes.
  2. Carry out Impact Analysis.
  3. Approve Changes.
  4. Carry out Changes.


Defined set of functional capabilities for a software Configuration Item (CI)  is called the version or Software Configuration Item version.


Changes to a version to correct only errors in design logic but doesn’t affect documented functional capabilities since none of the requirements  have changed.


Variation of a version developed to run on  different types of Hardware


Provide slightly different facilities for different users.


Two diverging versions may be merged  to create a single new version combining both set of change requests.

Note: Merge operations are typically done interactively with tool assistance.

CI Promotion

A configuration Item may be promoted from one developmental baseline to another to signify a change in a CI’s internal developmental state.


A release is used to designate certain promotions of CIs that are distributed outside the development organization.

Process to Identify what the different baselines consists of is known is Configuration Identification.

Set labeling and identification conventions for the CI’s.

Every CI has it’s identity that is used to keep change records and it shows that some particular CI  belongs to some particular baseline . Particular CI has following attributes and it is identified through these attributes.

Basic Configuration Item Information

1) Item Identity

2) Baseline to which it belongs

3) Relationship to other Items

4) Version

5) Variant

Methodology to control change in SDLC is as follows.

Change Request ( CR ) Submission

Technical and business evaluation and Impact Analysis

Change Control Board ( CCB ) approval

Engineering Change Order (ECO) generation stating

Changest to be made in CI

Criteria for reviewing the changed CI

CI’s Check Out

Change made and reviewed

CI’s Check In

Phase Baseline

1) Feasibility Study, Requirements Definition                                  1)  Functional Baseline

2) SRS, Interface Specification                                                                2) Allocated Baseline

3) Detailed Design                                                                                        3) Design Baseline

4) Source and object code,User Manual,Test documents              4) Product Baseline

5) Installation                                                                                               5) Operational Baseline


Milestone is the end of a stage or phase of a project of  at which one or more deliverables are actually delivered to the client.


Example of a milestone is the milestone on the road that shows that you have travelled a particular distance ( traveled distance ), mean to say that it is the symbol of completion.

Similarly , in the SDLC Milestone shows the completion job/ completed deliverables. When milestone reaches then it shows that it’s time to deploy/ handle deliverables to the client.


In the Configuration Management process, Baseline is the logical label for some items/deliverable that indicates on it’s completion milestone in the development process has been reached.

Note: Baseline is the identifier to the Milestone that acts an alert about Milestone.

Software Configuration Management (SCM) has two major types regarding items

1) Development Item

2) Configuration Item

Items that are not approved yet are known as Development Item.

Development Items can be changed without any formal approval.

Configuration Item

Approved and accepted deliverable is known as Configuration Item.

Changes are made through formal change control procedure.

Typical Software Configuration Items

List of CI’s involved in the Software Configuration Mangement process is as follows.

  •  Managemenet Plans
  • Specifications ( Requirements, Design )
  • User Documentation
  • Test Design, Case and procuedure specifications
  • Test data and test generation procedures
  • Data dictionaries and databases
  • Source code, executable code
  • Libraries
  • Maintenance documentation
  • Support software