Software Configuration Management (SCM)

The process of identifying, organizing, and controlling

Software Configuration Management changes to the software during development and
maintenance.
Art of coordinating software development to minimize confusions
• SCM is a support activity that makes technical and managerial
activities more effective

• SCM operates throughout the SW life-cycle

1 2

Benefits of SCM Why Products change ?

• Improves • Requirements change during and after development
• Product protection
• Product visibility • Errors are found and need correction
• Product control
• Team communication
• Variants are needed
• Customer confidence
• Decreases
• Rework
• Confusion
• Project risk

3 4

Problems of Change Causes of Change

Which component ? Which version ? • Evolutionary changes
• the system evolves as it passes through various stages in the development
cycle
• Double (or multiple) maintenance
• Updates to shared data
• Revolutionary changes
• Simultaneous update
• such change is caused by the system being unable to satisfy the user’s
requirements or the customers or producers expectations

5 6

1
SCM Activities are done to….. Software Configuration Item (SCI)

• SCM activities are developed to • Items are carefully identified

• As the software process progresses, the number of software
(1) identify change configuration items (SCIs) grows rapidly
(2) control change
(3) ensure that change is being properly implemented
(4) report change to others who may have an interest

7 8

The Software Configuration

What Are These Changes?

changes in
business requirements
programs documents changes in
technical requirements
changes in
user requirements other
documents

The pieces data software models

Project
Plan
data
Test
code

9 10

Typical SW Configuration Items (CIs) Milestones vs Baselines

• Management plans Milestone
• Specifications (requirements, design)
A milestone is the end of a stage or phase of a project at which one or
• User documentation
more deliverables are actually delivered.
• Test design, case and procedure specifications
• Test data and test generation procedures
• Data dictionaries and databases Baselines
• Source code, executable code A baseline is that collection of items which when complete indicates
• Libraries that a milestone in the development process has been reached.
• Maintenance documentation
• Support software

11 12

2
Baselines Baselines modified
SCIs

• The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as: Project database
approved
• A specification or product that has been formally reviewed and agreed upon, that Software Formal
engineering SCIs technical SCIs
thereafter serves as the basis for further development, and that can be changed only tasks reviews
through formal change control procedures.
stored

SCIs

• a baseline is a milestone in the development of software that is extracted

marked by the delivery of one or more software configuration items SCM

controls
SCIs

and the approval of these SCIs that is obtained through a formal BASELINES:
System Specification
technical review Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System

13 14

Typical Baselines Baselines

PHASE BASELINE • Baselines serve as the basis for further development
Feasibility study Functional baseline
Requirements definition • Baselines can be changed only through formal change control
SRS, Interface spec. Allocated baseline procedures
Detailed design Design baseline
Source and Object code Product baseline
User manuals • Only items that have been approved and obtained through a formal
Test documents
technical review are accepted into the baseline.
Installation Operational Baseline

15 16

Baseline Management - Questions Baseline Management - Questions

• What baselines are required to be defined and managed? • Who must approve changes to baselines?
• Typically aligned with major milestones • Usually the Change Control Board (CCB)
• Applies to documents as well as code
• How and when are baselines created and physically controlled?
• How is the current software configuration defined? • Through the use of document control systems, code control tools, and
• A snapshot of everything the product has produced at some point in time procedures to prevent the making of unapproved changes

17 18

3
Baseline Management - Questions Baseline Management - Questions
• How are people informed of changes? • What information is required to process a change to a baseline?
• The CCB disseminates change information • A description of the proposed changes
• How are baselines verified? • Reasons for making the changes
• By reviews, inspections, and the testing of code • List of other items affected by the changes

• Are baselines tied to project milestones? • What tools, resources, and training are required to perform baseline
• Many are, but during coding many may not be change assessment?
• File comparison tools to identify changes
• Resources and training depend on size and complexity of project

19 20

Baseline Management - Questions Baseline Management - Questions

• What metrics should be used to assess changes to a baseline? • How are unauthorized changes to source code prevented, detected,
• Complexity and corrected?
• Average module size • No way to prevent unauthorized changes
• Number of modules changed • Provide software engineers with training
• Number of bugs fixed and verified • A commercial available SCM systems provide adequate protection
• Code coverage • Unauthorized changes should be caught during assessment procedures

21 22

Baseline Management - Questions Baseline Change Assessment

• What tools, resources, and training are required to perform baseline • Helps to identify recent changes that may be responsible for
management? problems
• A fully featured SCM tool • Helps to ensure that only authorized changes are made
• On large projects a separate SCM group may be needed
• SCM training is required for all involved in the process

23 24

4
Configuration Identification Configuration Identification
• Identify what the different baselines will consist of • Configuration identification is the process of identifying the attributes
that define every aspect of a configuration item.
• Set labelling and identification conventions for the CIs • A configuration item is a product (hardware and/or software) that has
an end-user purpose.
• These attributes are recorded in configuration documentation and
baselined.
• Baselining an attribute forces formal configuration change control
processes to be effected in the event that these attributes are
changed.

25 26

Basic Conf Item information Configuration objects

• Item identity • A configuration object has a name, attributes and is ‘connected’ to
• Baseline to which it belongs other objects by relationships
• Basic object
• Relationships to other items • Aggregate object
• Version • Compositional relationship (curved arrow)
• Variant • Inter-relationship (double-headed straight arrow)

27 28

Identification of objects in the software

configuration
Software Configuration Objects
Data model

Design spec ific ation

• 2 types of objects can be identified data design

• Basic object
architectural design
module design
interface design
• A ‘unit of text’ that has been created by a software engineer during Component N
analysis, design, coding or testing
interface description
• Aggregate objects algorithm desc ription
Test specific ation PDL
• A collection of basic objects and other aggregate objects
(conceptually it can be viewed as a named (identified) list of tes t plan
tes t proc edure
pointers that specify basic objects) tes t cases

Source code

29 30

5
SCM Repository Repository Content
use-cases
analy sis m odel

• The SCM repository is the set of mechanisms and data structures that
business rules source code
business funct ions scenario-based diagram s obj ect code
organizat ion st ruct ure flow-orient ed diagram s sy st em build inst ruct ions
class-based diagram s

allow a software team to manage change in an effective manner

inform at ion archit ect ure
behav ioral diagram s Const ruct ion
design m odel
Cont ent
archit ect ural diagram s

• The repository performs or precipitates the following functions:

Business int erface diagram s
Cont ent com ponent -lev el diagram s
t echnical m et rics t est cases

•
t est script s
Data integrity t est result s
qualit y m et rics
Model
• Information sharing Cont ent
V&V

• Tool integration Cont ent

• Data integration Project

• Methodology enforcement project est im at es

Management
Cont ent
project schedule

• Document standardization SCM requirem ent s

change request s Document s
Project Plan
SCM/ SQA Plan
change report s
Sy st em Spec
SQA requirem ent s
Requirem ent s Spec
project report s/ audit report s
Design Docum ent
project m et rics
Test Plan and Procedure
Support docum ent s
User m anual

31 32

Repository Features SCM Elements

• Versioning. • Component elements—a set of tools coupled within a file management system (e.g., a
• saves all of these versions to enable effective management of product releases and to permit database) that enables access to and management of each software configuration item.
developers to go back to previous versions
• Dependency tracking and change management. • Process elements—a collection of procedures and tasks that define an effective approach
• The repository manages a wide variety of relationships among the data elements stored in it.
to change management (and related activities) for all constituencies involved in the
management, engineering and use of computer software.
• Requirements tracing.
• Provides the ability to track all the design and construction components and deliverables that result
from a specific requirement specification • Construction elements—a set of tools that automate the construction of software by
ensuring that the proper set of validated components (i.e., the correct version) have
• Configuration management. been assembled.
• Keeps track of a series of configurations representing specific project milestones or production releases.
Version management provides the needed versions, and link management keeps track of
interdependencies. • Human elements—to implement effective SCM, the software team uses a set of tools
• Audit trails. and process features (encompassing other CM elements)
• establishes additional information about when, why, and by whom changes are made.
33 34

The SCM Process SCM Functions

• SCM process addresses the following questions
• Identification of software items and products
• How does an organization identify and manage the many existing versions of a program in a
manner that will enable change to be accommodated efficiently? • Definition of Baselines
• How does a software team identify the discrete elements of a software configuration?
• How does an organization manage the many existing versions of a program (and its • Access controls
documentation) in a manner that will enable change to be accommodated efficiently?
• Progressing defect reports
• How does an organization control changes before and after software is released to a
customer? • Progressing change requests
• Who has responsibility for approving and prioritizing changes?
• How can we assure that changes have been made properly?
• Recording item status
• What mechanism is used to appraise others of changes that are made? • Controlling releases (versions and variants)
… these questions lead to the definition of 5 SCM tasks
• Reporting

35 36

6
 The SCM Process
5 SCM tasks Software
Vm.n

• Identification reporting

• Version & Change control configuration auditing

• Status accounting version control

• Configuration auditing change control

• Status reporting
identification

SCIs

37 38

Version Control SCM Terminology

• An entity is composed of objects at the same revision level Version
A SW CI having a defined set of functional capabilities.

• A variant is a different set of objects at the same revision level and Revisions
coexists with other variants
changes to a version to correct only errors in design logic but does not
affect documented functional capabilities since none of the requirements
have changed.
• A new version is defined when major changes have been made to
one or more objects
Variants
a variation of a version developed to run on different types of HW, or to
provide slightly different facilities for different users.
39 40

Examples Merging
successive versions • Two diverging versions may be merged to create a single new version
combining both set of change requests.
1.1 1.2 1.3 1.4

• Merge operations are typically done interactively with tool assistance

branching versions (variants)

1.3.1.1 1.3.1.2

1.1 1.2 1.3 1.4

41 42

7
Version Management Version Control
• Being able to reliably build and recreate versions of a product as it • Version control combines procedures and tools
evolves and after it is released. • to manage different versions of configuration objects that are created during the software
process
• Being able to retreat to a previous version if necessary • for managing the creation and use of multiple occurrences of Conf Items in the SCM
repository
• Being able to recreate all versions of the product that customers have
• A version control system implements or is directly integrated with four major
capabilities:
• a project database (SCM repository) that stores all relevant configuration objects
• a version management capability that stores all versions of a configuration object (or enables
any version to be constructed using differences from past versions)
• a make facility that enables the software engineer to collect all relevant configuration
objects and construct a specific version of the software.
• an issues tracking (also called bug tracking) capability that enables the team to record and
43 track the status of all outstanding issues associated with each configuration object. 44

Configuration Version Control Change Control

• Version control is a set of procedures and tools for managing the • Change request
creation and use of multiple occurrences of Cis in the SCM repository • submitted and evaluated to assess technical merit and impact on the other configuration
objects and budget
• Required version control capabilities
• An SCM repository that stores all relevant configuration objects • Change report
• A version management capability that stores all versions of a configuration • contains the results of the evaluation
object (or enables any version to be constructed using differences from past
versions) • Change control authority (CCA)
• To make facility that enables the software engineer to collect all relevant • makes the final decision on the status and priority of the change based on the change report
configuration objects and construct a specific version of the software
• Issues tracking (bug tracking) capability that enables the team to record and • Engineering change order (ECO)
track the status of all outstanding issues associated with each configuration • generated for each change approved (describes change, lists the constraints, and criteria for
object review and audit)

45 46

ConfigurationChange Control Configuration Control

• Change control is a procedural activity that ensures quality and consistency • Enforces a rigorous change control mechanism
as changes are made to a configuration items
• A change request is submitted to a configuration control authority, which is
usually a change control board (CCB) • Requires formal procedures to
• The request is evaluated for technical merit, potential side effects, overall impact on • request changes
other configuration items and system functions, and projected cost in terms of • carry out impact analysis
money, time, and resources
• approve changes
• The baselined CI is obtained from the SCM repository • carry out changes
• Access control governs which software engineers have the authority to access and
modify a particular configuration object
• Synchronization control helps to ensure that parallel changes performed by two
different people don't overwrite one another

47 48

8
Change Control Change Management Methodology

• Submission of Change Request (CR)

• Object to be changed is checked-out of the project database subject to access
control parameters for the object • Technical and business evaluation and impact analysis
• Approval by Change Control Board
• Modified object is subjected to appropriate SQA and testing procedures • Engineering Change Order (ECO) is generated stating
• changes to be made
• Modified object is checked-in to the project database and version control • criteria for reviewing the changed CI
mechanisms are used to create the next version of the software
• CI’s checked out
• Synchronization control • Changes made and reviewed
• used to ensure that parallel changes made by different people don’t overwrite one another • CI’s checked in
49 50

Change Control Process—I Change Control Process-II

need for change is recognized
assign people to SCIs
change request from user
check-out SCIs
developer evaluates
make the change
change report is generated
review/audit the change
change control authority (CCA) decides

request is queued for action, Check-in SCIs that have been changed
Engg. Change Order (ECO) change request is denied
is generated establish a “baseline” for testing
user is informed
change control process—II change control process—III
51 52

Change Control Process-III Change Control Board

perform SQA and testing activities • A group consisting of representatives of user, customer, producer.

Promote changes for inclusion in next release • Responsibilities:

• to approve, monitor and control baselines
rebuild appropriate version of software • to approve, monitor, and control changes
• to authorise changes
review/audit the change to all configuration items • CCB concerns in change approval
• technically ok solution, cost, schedule, configuration of the whole system,
include changes in new version (release) user satisfaction

Distribute new version

53 54

9
 Software Libraries Three Kinds of Software Libraries
• SW libraries provide the means for implementing SCM Dynamic library (programmer’s library)
• programmer’s workspace

• The number and kind of libraries will vary from project to project . It
depends on the levels of control needed. Controlled library (master library)
• used for managing the current baseline(s) and for controlling changes made
to them

Static library (software repository)

• used to archive various baselines released for general use

55 56

Forward Delta Files

Techniques for storing Versions User CM System

foward
• Full files delta files
Vn Vn
• Forward Delta files version version + first
version
• Reverse Delta files
changes
• The set of differences between two versions is called a delta.
Vn+1 Vn+1
version version

Vn
version

57 58

Reverse Delta Files

User CM System
Auditing
reverse
delta files
Vn+1 Vn+1
version new recent
version + Change
Requests SQA
Plan
changes SCIs

recent version
Vn Vn
version version

SCM Audit

59 60

10
Configuration Auditing Configuration Audit
• Ensure existence of required components • A configuration audit establishes that product integrity has been
• Maintains integrity of each configuration maintained and that changes have taken place in an orderly and controlled
manner.
• Audits ensure each configuration contains the correct versions
• Configuration auditing is an SQA activity that helps to ensure that quality is
• Review configuration changes maintained as changes are made
• Audits generally correspond to major milestones • It complements the formal technical review and is conducted by the SQA
group

• Audit for:
• Audit of the SW product
• Audit of SCM activities

61 62

Configuration Auditing Types of Audits

• A configuration audit ensures that • In-process audits – verify the consistency of the design as it evolves through the development process

• The correct CIs (by version) have been incorporated into a specific build • Functional audits – verify that functionality and performance are consistent with requirements defined in
• That all documentation is up-to-date and consistent with the version that has the SRS
• it verifies that each CI in the product has been tested to determine that it satisfies the functions defined in the specifications
been built or contract(s) for which it was developed.

• Physical audits – verify that the as-built version of software and documentation are internally consistent and
• It addresses the following questions ready for delivery
• consists of determining that all items identified as being part of the configuration are present in the Product baseline
• Has the change specified been made? Have any additional modifications been incorporated?
• Has a formal technical review been conducted to assess technical correctness? • it must also establish that the correct version and revision of each part are included in the product baseline and that they
correspond to information contained in the baseline’s configuration status report.
• Has the software process been followed, and have software engineering standards been properly
applied?
• Has the change been "highlighted" and "documented" in the CI? Have the change data and change • Quality system audits – independent assessment of the compliance to the software QA plan
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 CIs been properly updated?
63 64

Status Accounting Configuration Status Accounting

Change
• Identify changes made to configuration
Change
Reports • Maintain records of changes to all objects throughout the application’s life
Requests ECOs
cycle
SCIs
• Identify work in process
• Document contents of all builds
• Generate periodic status reports
Status Accounting

Reporting
65 66

11
Configuration Status Accounting Requirements Status Accounting
• Identifying the types of information that project managers need • Provides
• a mechanism for administrative tracking and reporting of all SW items identified and
controlled.
• Identifying the degree of control needed by project management • information about each change to those personnel in an organization with a need to know

• Status Accounting is also called Configuration status reporting (CSR)

• Identifying the reports required and the different audiences for each report
• Examples of Status reports:
• the status of proposed changes
• Identifying the information required to produce each report
• the status of approved changes
• the baselines and the approved changes associated with each baseline
• the date when each revision of each CI was recorded
• deficiencies identified by configuration audit

67 68

Status reporting
• Answers what happened, who did it, when did it happen, and what else
will be affected?

• Sources of entries for configuration status reporting

• Each time a CI is assigned new or updated information
• Each time a change is approved by the CCB
• Each time a configuration audit is conducted
SCM Planning
• The configuration status report
• Placed in an on-line database or on a website for software developers and
maintainers to read
• Given to management and practitioners to keep them appraised of important
changes to the project CIs

69 70

SCM planning Software Configuration Management Plan

• Software configuration management planning starts during the early • Defines the types of documents to be managed and a document
phases of a project. naming scheme.
• Defines who takes responsibility for the CM procedures and creation
• The outcome of the SCM planning is the Software Configuration of baselines.
Management Plan (SCMP) which might be extended or revised during • Defines policies for change control and version management.
the rest of the project. • Describes the tools which should be used to assist the CM process
and any limitations on their use.
• The SCMP can either follow a public standard like the IEEE 828, or an • Defines the configuration management database used to record
internal (e.g. company specific) standard. configuration information.

71 72

12
SCM Plan SW Configuration Management Plan

The SCM Plan is prepared in Project Initiation phase. It documents -- IEEE Standard 828-1990 for SCM Plan

- what SCM activities are to be done

1.Introduction
- how they are to be done
- who is responsible for doing specific 2.SCM Management
activities 2.1 Organization
2.2 SCM Responsibilities
- when they are to happen
2.3 Applicable policies, directives and procedures
- what resources are required

73 74

SW Configuration Management Plan SW Configuration Management Plan

3.SCM Activities (3. SCM Activities)

3.1 Configuration identification 3.3 Configuration Status Accounting
3.1.1 Identifying configuration items 3.4 Configuration Audits and Reviews
3.1.2 Naming configuration items 3.5 Interface control
3.1.3 Acquiring configuration items 3.6 Subcontractor/Vendor control
3.2 Configuration control
3.2.1 Requesting changes 4.SCM Schedules
3.2.2 Evaluating changes 5.SCM Resources
3.2.3 Approving or disapproving changes
6.SCM Plan maintenance
3.2.4 Implementing changes

75 76

Roles for SCM Tasks for the Configuration Managers

• Configuration manager
Define configuration items

• Change Control Board

includes representatives of Define promote /release policies

- user
- customer Define responsibilities
- developer

77 78

13
Questions

79

14