Software Configuration

Management
Outline
 Software Configuration Management (SCM)
 What is SCM
 What is software configuration
 Sources of Change
 People in typical SCM Scenario
 Baselines
 Configuration objects
 SCM Repository
 SCM Process
 Change Control
 Version Control
 CSR
What is SCM?
 Change management is commonly called software
configuration management (SCM or CM)

 Babich defines Configuration Management as:

 the art of identifying, organizing and controlling
modifications to the software being built by a programming
team.

 SCM activities have been developed to manage

change throughout the life cycle of computer
software

 SCM can be viewed as a quality assurance activity

What is SCM? (Contd.)
 SCM is a set of activities designed to
manage change by:
 Identifying s/w work products that are likely to
change,
 Establishing relationships among them,
 Defining mechanisms for managing different
versions of these work products
 Controlling changes
 And auditing and reporting on the changes made
Difference between Software
Support and SCM

 Support is a set of s/w engg. activities that

occur after software has been delivered to
the customer and put into operation.

 While SCM is a set of tracking and control

activities that initiate when the s/w engg
project begins & end only when the s/w is
taken out of operation
What is software configuration?
 The items that comprise all information
produced as part of the software process
are collectively called a software
configuration
 This information (also termed as output of
software process) is broadly divided into:
 Computer programs (both source level &
executable forms)
 Work products that describe the computer
programs
 Data (contained within program or external to it)
 Sources of Changes
 New business or market conditions
 dictate changes in product requirements or business
rules.
 New customer needs
 demand modification of data produced by information
systems, functionality delivered by products, or services
delivered by a computer-based system.
 Reorganization or business growth/ downsizing
 causes changes in project priorities or software engg
team structure.
 Budgetary or scheduling constraints
 cause a redefinition of the system or product.
People involved in a typical SCM
Scenario
 Project Manager
 In charge of s/w group
 Ensures that product is developed within time frame
 Monitors development, recognizes & reacts to problems
 by generating & analyzing reports about system status
 By performing reviews
 Configuration Manager
 In charge of CM procedures
 Ensures that procedures & policies for creating,
changing & testing of code are followed
 To control changes in code, introduces mechanisms for
official change requests, their evaluation & authoriza-
tion.
People involved in a typical SCM
Scenario
 Software engineers
 Work efficiently without interfering in each other’s code
creation, testing & supporting documentation.
 But at the same time communicate & coordinate
efficiently by
 Updating each other about tasks required & tasks
completed
 Propagating changes across each others work by
merging files
 Customers
 Use the product
 Follows formal procedures of requesting changes and
for indicting bugs in the product
Baselines
 IEEE defines baseline as:
 A specification or product that has been formally reviewed
and agreed upon, that thereafter serves as basis for further
development, and that can be changed only through formal
change control procedures.
 Before a s/w configuration item becomes a baseline,
changes may be made quickly & informally.
 However, once it becomes a baseline, formal
procedures must be applied to evaluate & verify every
change.
 Refer to figure 27.1 to see steps for forming a
baseline.
 Baselined SCIs and Project DB

Modified
SCIs
PROJECT DB

S/w engg FTRs Approved SCIs

SCIs
tasks
Stored SCIs

SCM Controls Extracted SCIs Baselines:

Configuration Objects
 SCIs are organized to form configuration objects.
 A config. object has a name, attributes and is
related to other objects.
 Example:
 Test Specification – Config. Object
 It comprises of SCIs like Test Plan, Test Procedure, Test
Cases
 It is related to config. object SourceCode
 Config. Objects are related to other cong. objects,
the relationship is either compositional (part-of
relationship) or interrelated.
 In related config. objects, if one of them changes,
the other one has to be changed.
SCM Repository
 In early days of s/w engg, software configuration
items were maintained as paper documents (or
punch cards), placed in files and folders.
 The problems of this approach were:
 Finding a configuration item when it was needed was
often difficult
 Determining which items were changed, when and by
whom was often challenging
 Constructing a new version of existing program was error-
prone & time consuming
 Describing complex relationships among configuration
items was virtually impossible
 Today SCIs are maintained in a project database or
repository.
 It acts as the center for accumulation and storage of
SCIs
 Role of repository
 SCM Repository is a set of mechanisms & data
structures that allow a software team to manage
change in an effective manner.
 It provides functions of a DBMS but in addition has
the following functions:
 Data integrity
 Info sharing
 Tool integration
 Data integration
 Methodology enforcement
 Document standardization
SCM Process
 SCM process defines a series of tasks
having 4 primary objectives
 To identify all items that collectively define the
s/w configuration.
 To manage changes to one or more of these
items.
 To facilitate construction of different versions of
an application.
 To ensure that s/w quality is maintained as
configuration evolves over time.
Version Control
 Combines procedures and tools to manage the
different versions of configuration objects created
during the software process.
 1. Entity Definition: The base unit or artifact managed in the SCM system. It is a logical or
physical item, such as a file, document, or software module.
 Key Idea: The core item without considering its changes or variations.
 Example: A source code file named main.c

 2. Version Definition: A specific instance or revision of an entity that results from changes made
over time.
 Key Idea: Tracks the evolution of the entity through modifications.
 Example: main.c (Entity) →
 Version 1: Initial implementation of main.c.
 Version 2: Added a new function to main.c.
 Version 3: Fixed a bug in main.c.

 3. VariantDefinition: A variation of an entity designed to meet different requirements,

environments, or platforms while coexisting with other variants.
 Key Idea: A parallel branch of an entity with differences tailored for specific use cases.
 Example:main.c (Entity) →
 Variant 1: A version of main.c for Windows with Windows-specific system calls.
 Variant 2: A version of main.c for Linux with Linux-specific system calls.
Version Control System
 A number of automated tools are available for
version control.
 CVS (Concurrent version System) is an example
which is based on RCS (Revision Control System)
 CVS features
 Establishes a simple repository.
 Maintains all versions of a file in a single named file by
storing only the differences between progressive versions
of the original file.
 Protects against simultaneous changes to a file by
establishing different directions for each developer
Change Control
 A Change request is submitted and evaluated
to assess technical merit and impact on the
other configuration objects and budget
 Change report contains the results of the
evaluation
 Change control authority (CCA) makes the final
decision on the status and priority of the change
based on the change report
 Engineering change order (ECO) is generated
for each change approved (describes change,
lists the constraints, and criteria for review and
audit)
Change Control (Contd.)
 Object to be changed is checked-out of the
project database subject to access control
parameters for the object
 Modified object is subjected to appropriate SQA
and testing procedures
 Modified object is checked-in to the project
database and version control mechanisms are
used to create the next version of the software
 Synchronization control is used to ensure that
parallel changes made by different people don't
overwrite one another
Software Configuration Audit
 To ensure that a change has been properly
implemented, FTRs and software config. audits are
used.
 A Software Config. Audit complements the FTR by
addressing the following questions:
 Has the change specified by the ECO been made without
modifications?
 Has an FTR been conducted to assess technical
correctness?
 Was the software process followed and software engineering
standards applied?
 Do the attributes of the configuration object reflect the
change?
 Have the SCM standards for recording and reporting the
change been followed?
 Were all related SCI's properly updated?
Configuration Status Reporting
 CSR addresses the following questions:
 What happened?
 Who did it?
 When did it happen?
 What else will be affected by the change?
 CSR entries are made when:
 A SCI is assigned new or updated identification
 Change is approved by CCA
 Config. Audit is conducted
 CSR is generated on regular basis.