Software Configuration

Management

1
Software Configuration
Management
Definition
1. Software Configuration Management (SCM) is the
discipline of controlling the evolution of software
systems.
2. Roger Pressman says that SCM is a "set of
activities designed to control change by
identifying the work products that are likely to
change, establishing relationships among them,
defining mechanisms for managing different
versions of these work products, controlling the
changes imposed, and auditing and reporting on
the changes made."

2
3. Wayne Babich describes SCM as
"the art of identifying, organizing,
and controlling modifications to
the software being built by a
programming team. It maximizes
productivity by minimizing
mistakes."

3
 The “First Law”

No matter where you are in the system life cycle,

the system will change, and the desire to change
it will persist throughout the life cycle.

Bersoff, et al, 1980

What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents

software models
Project
Plan
data
Test
code
 Why is it needed?
 Software changes constantly.
 Change causes chaos.
 SCM helps prevent change chaos:
 Tracks development history,
 Prevents or reconciles conflicting changes,
 Tracks configurations and baselines,
 Tracks error reports and fixes,
 Automates configuration selection,
 keeps software in well-defined state.
 SCM is indispensable for the development and
maintenance of large, long-lived software.

6
Symptoms of the
Change Chaos
 Problems of identification and tracking:
 “This program worked yesterday. What happened?”
 “I fixed this error last week. Why is it back?”
 “Where are all my changes from last week?”
 “This seems like an obvious fix. Has it been tried
before?”
 “Who is responsible for this change?”
 Problems of version selection
 Software Delivery Problems

7
 Why Is SCM Important?
 CM enhances the ability to provide
maintenance support necessary once the
software is deployed.
 The National Institute of Standards and
Technology (NIST) says that software will be
changed to adapt, perfect, or correct it.
Pressman points out that new business, new
customer needs, reorganizations, and
budgetary or scheduling constraints may
lead to software revision.
 It helps to eliminate confusion, chaos,
double maintenance, the shared data
problem.

8
Who Is Involved in SCM?
 Virtually everyone on a software project
is affected by SCM. From the framers of
the project plan to the final tester, we
rely on it to tell us how to find the object
with the latest changes.
 During development, when iterations are
informal and frequent, little needs to be
known about a change except what it is,
who did it, and where it is.

9
Who Is Involved in SCM?
(Contd..)
 In deployment and baselining, changes
must be prioritized, and the impact of a
change upon all customers must be
considered.
 A change control board (CCB) is the
governing body for modifications after
implementation.

10
 The Software Configuration

programs documents

The pieces data

Change & SCM
Software Engineering
SCM
tools • identification
• version control
methods
• change control
procedures • auditing
a TQM foundation • reporting
• construction
How Can Software Configuration Be
Implemented in Your Organization?
 We used to say, "Make a plan and stick with it—
never waffle," and "Requirements must be
frozen—how else will we know what to code?"
Now, we say, "Plans are living documents—they
will be in a continual state of change as project
knowledge increases." We now know that
requirements are never frozen—they merge,
evolve and become expanded, enhanced, and
extended. As long as artifacts of software
development can undergo change, we will need
some method of managing the change.

13
How Can Software Configuration Be
Implemented in Your Organization? (Contd..)
 Because SCM is such a key tool in
improving the quality of delivered
products, understanding it and how to
implement it in your organization and on
your projects is a critical success factor.
The SCM provide you with a composite
SCM plan template for use in any of your
projects. The issues and basics for a
sound SCM system are as follows:

14
How Can Software Configuration Be
Implemented in Your Organization? (Contd..)
The Four basic requirements for an SCM
system
 SCM principles
 Planning and organizing for SCM
 SCM Tools
 Benefits of SCM
 Path to SCM implementation

15
The Four Basic Requirements for an
SCM System
 Identification, Control, Audit, and Status
Accounting are the four basic
requirements for a software
configuration management system.
 These requirements must be satisfied
regardless of the amount of automation
within the SCM process.
 An SCM tool, a tool set, or a combination
of automated and manual procedures
may satisfy all four.

16
The SCM Process
 Primary Objectives of the
SCM Process
 Identify all items that collectively define the
software configuration
 Manage changes to one or more of these items
 Facilitate construction of different versions of an
application
 Ensure the software quality is maintained as the
configuration evolves over time
 Provide information on changes that have
occurred

(Compare this process to the five SCM tasks)

 SCM Questions
 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 documentation) in a
manner that will enable change to be accommodated
efficiently?
 How does an organization control changes before and
after software is released to a customer?
 Who has responsibility for approving and ranking
changes?
 How can we ensure that changes have been made
properly?
 What mechanism is used to appraise others of changes
that are made?
 SCM Process
Status reporting
Configuration auditing
Version control
Change control
Identification
SCI SCI
SCI SCI
 SCM Process
 Concentric layers (from inner to outer)
 Identification
 Change control
 Version control
 Configuration auditing
 Status reporting
 SCIs flow outward through these layers during their
life cycle
 SCIs ultimately become part of the configuration of
one or more versions of a software application or
system

21
Identification
 Identification separately names each SCI and then
organizes it in the SCM repository using an object-
oriented approach
 Objects start out as basic objects and are then
grouped into aggregate objects
 Basic Object – A unit of information that has
been created by a S/w engg. During analysis,
design,code or test.
 Exe:- Section of a req. spec.
 Part of a design model
 Source code for a component
 Suite of test cases that are used to exercise
the code

22
Identification
 Aggregate Object:- Collection of basic object & other
aggregate object.
 Exe:- Design Specification
 Class Diagram<Part-of> Analysis Model
 Analysis Model<Part of> Requirement specification

 Each object has a set of distinct features that identify

it
 A name that is unambiguous to all other objects
 A description that contains the SCI type, a project identifier, and change
and/or version information
 List of resources needed by the object
 The object realization (i.e., the document, the file, the model, etc.)

23
 Identification
 Each software part is labeled so that it can be
identified. Furthermore, there will be different
versions of the software parts as they evolve over
time, so a version or revision number will be
associated with the part.
 The key is to be able to identify any and all
artifacts that compose a released configuration
item. Think of this as a bill of materials for all the
components in your automobile.
 When the manufacturer realizes that there has
been a problem with parking brakes purchased
from a subcontractor, it needs to know all the
automobile models using that version of the
parking brake. It is the same with software.

24
Identification (Contd..)
 If we are building a multimedia system
that has audio MPEG3 drivers for
Windows 98, Windows 2000, Windows
CE, Linux, and FreeBSD operating
systems, how do we find out which
releases are impacted when we find an
error in the Linux product?
 You must go back to your SCM system to
identify all the common components in
all operating system releases that are
impacted.
25
Control
 In the context of configuration
management, "control" means that
proposed changes to a Configuration
Item (CI) are reviewed and, if approved,
incorporated into the software
configuration.
 The goal is to make informed decisions
and to acknowledge the repercussions
associated with a change to the system.
 These changes may impact budgets,
schedules, and associated changes to
other components.

26
Control (Contd..)
 If a problem is reported in a released
product, software engineers must act
quickly to evaluate repercussions—a
"fix" for one client's version of the
product may be dangerous to another.
 The control inherent in an SCM system
shows each version in which the flawed
component appears.

27
 Change Control Process—I
need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority decide

request is queued for action change request is denied

change control process—II user is informed

28
Change Control Process—II
assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a “baseline” for testing

change control process—III

29
Change Control Process—III
perform SQA and testing activities

check-in the changed SCIs

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

Distribute the new version 30

 Change Control
 Change control is a procedural activity that ensures
quality and consistency as changes are made to a
configuration object
 A change request is submitted to a configuration
control authority, which is usually a change control
board (CCB)
 The request is evaluated for technical merit, potential side effects, overall
impact on other configuration objects and system functions, and projected cost
in terms of money, time, and resources
 An engineering change order (ECO) is issued for each
approved change request
 Describes the change to be made, the constraints to follow, and the criteria for
review and audit
 The baselined SCI is obtained from the SCM repository
 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
 Version Control
 Version control is a set of procedures and tools for
managing the creation and use of multiple
occurrences of objects in the SCM repository
 Required version control capabilities
 An 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
 Issues tracking (bug tracking) capability that enables the team to record and
track the status of all outstanding issues associated with each configuration
object
 The SCM repository maintains a change set
 Serves as a collection of all changes made to a baseline configuration
 Used to create a specific version of the software
 Captures all changes to all files in the configuration along with the reason
for changes and details of who made the changes and when
 Configuration Auditing
 Auditing an SCM system means that approved
requested changes have indeed been
implemented.
 The audits allow managers to determine
whether software evolution is proceeding both
logically and in conformance with requirements
for the software.
 The SCM system should document changes,
versions, and release information for all
components of each configuration item.
 When such documentation is in place, auditing
becomes a straightforward analysis task.

33
Configuration Auditing
 Configuration auditing is an SQA activity that helps to
ensure that quality is maintained as changes are made
 It complements the formal technical review and is
conducted by the SQA group
 It addresses the following questions
 Has the change specified in the ECO been made? 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" and "documented" in the SCI? Have the change
data and change 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?
 A configuration audit ensures that
 The correct SCIs (by version) have been incorporated into a specific build
 That all documentation is up-to-date and consistent with the version that has been
built
Configuration Auditing

Change
Requests SQA
Plan
SCIs

SCM Audit
Status Reporting
 Configuration status reporting (CSR) is also
called status accounting
 Provides information about each change to those
personnel in an organization with a need to know
 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 SCI is assigned new or updated information
 Each time a change is approved by the CCB and an ECO is issued
 Each time a configuration audit is conducted
 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 SCIs
Status Reporting
 Reports and documentation produced by
the status accounting function are the
auditable entries.
 All approved parts of a software
configuration must be accounted for, and
the software parts list must reflect the
transition from part CIn to CIn+1.
 This accounting provides the historic
information to determine both what
happened and when on the software
project.

37
 Status Reporting
 Status accounting enables the auditing
requirement of the SCM. As a project
manager, the status accounting holds a
wealth of information on the amount of
effort required throughout the life cycle
of the product in its development and
maintenance.
 This is critical to the software project
manager in making estimates for new
systems based on historic information.
The SCM can be used as one of the key
components of the project managers'
metrics system

38
Status Reporting
Change
Change
Reports ECOs
Requests
SCIs

Status Accounting

Reporting