Software configuration management (SCM)

Software configuration management (SCM)

Software configuration management is a set of tracking and

control activities that begin when a software engineering project
begins and terminate only when the software is taken out of
operation
is concerned with the policies, processes, and tools for
managing changing software systems
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
auditing and reporting on the changes made.

Sources of Change

New business or market conditions

New customer needs

causes changes in project priorities or software engineering team

structure

Budgetary or scheduling constraints

demand modification of data, functionality, or services

Business reorganization

dictate changes to SW requirements or business rules

cause system to be redefined

Software Configuration Management Tasks

Identification

Version control

ensure changes made properly

Reporting

authority to approve and prioritize changes

Configuration auditing

control changes before and after release to customer

Change control

tracking multiple versions to enable efficient changes

tell others about changes made

Software Configuration Items

Computer programs

Documentation

describing the computer programs (targeted at both technical

practitioners users

Data

both source and executable forms

contained within the program or external to it

Baselines

A baseline is a software configuration management concept

that helps us to control change without seriously impeding
justifiable change
a milestone in the development of software that is marked by
the delivery of one or more software configuration items and
the approval of these SCIs that is obtained through a formal
technical review

Identification
To

control and manage configuration items

each must be named

should be managed using an object-oriented
approach

Basic

objects

created by software engineers during analysis,

design, coding, or testing

Aggregate

objects

collections of basic objects and other aggregate

objects

Version Control
Combines procedures and tools to manage the
different versions of configuration objects created
during the software process
Represented in evolution graph

An entity is composed of objects at the same revision level

A variant is a different set of objects at the same revision level
and coexists with other variants
A new version is defined when major changes have been
made to one or more objects

Change Control

Change request

Change report

makes the final decision on the status and priority of the

change based on the change report

Engineering change order (ECO)

10

contains the results of the evaluation

Change control authority (CCA)

submitted and evaluated to assess technical merit and impact

on the other configuration objects and budget

generated for each change approved (describes change, lists

the constraints, and criteria for review and audit)

Change Control

11

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
used to ensure that parallel changes made by different
people dont overwrite one another

12

CONFIGURATION AUDIT

How can we ensure that the change has been properly

implemented?
Two approaches

formal technical review

focuses on the technical correctness of the configuration object that

has been modified

software configuration audit

13

formal technical reviews and the software configuration audit

complements the formal technical review by assessing a

configuration object for characteristics that are generally not
considered during review

Software Configuration Audit Questions

14

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?

Reporting

Configuration status reporting (sometimes called status

accounting) is an SCM task that answers the following
questions:

15

What happened?
Who did it?
When did it happen?
What else will be affected?

Each time a configuration audit is conducted, the results are

reported as part of the CSR task.
Output from CSR may be placed in an on-line database, so that
software developers or maintainers can access change
information by keyword category.
plays a vital role in the success of a large software development
project

ClearQuest

16

This tool is a change request management application that allows a

developer to track and monitor the change requests for a
configuration item
ClearQuest maintains its own database which stores all the change
requests in the form of records.
There are various categories of changes that can be done on a
product. These changes can be due to addition of new features,
detection of faults, activities etc.

Managing Configurations in Open Source

Projects

Version management

17

write access to the CVS repository is granted hence several hundred

developers can add new versions to it
Some make exception, as they use no tool at all for version control
such as

Linux

Contributions can only be applied to the repository by the

moderators and there is no version history, as they violate the

version control principle of immutability.
When a new release is created, the latest is duplicated into a
new release directory to conserve it even if development
continues,

Configuration Selection

18

Almost always the latest version of all files is used to build a

configuration
Since only one release is maintained (the latest) there is no
need to return to other configurations.
Only in the case where you want to install an older release
are they retrieved.
In the cases where one stable and one development release
are maintained concurrently they are run as two separate
projects

Change management

19

In traditional projects only approved change proposals are

assigned to developers.
In OSS the evaluation of change proposals is not explicit,
Anyone can propose a change and most often changes are
not even proposed before a change is submitted directly.
Change proposals might be prioritized implicitly or explicitly,
but an OSS project cannot assign tasks to developers
everyone works on what has been chosen.
Patches are reviewed in multiple steps before testing,
Contributions that are found ill-designed or have not so
sound ideas are rejected

Change Process for OSS

20

Release Management

21

Different from The traditional

No fixed release dates and labelling and release is mostly
arbitrary
When an internal release is getting nearer, the development
branch enters a freeze stage.
Initially, the soft freeze stage means that new features, which
break compatibility are discouraged, but not forbidden.
They then move to a hard freeze, which in practice means
that any contribution that will change an interface is
forbidden. Only bug fixes are allowed.

Reading

Pressman Software engineering: a practitioners approach Chapter 9

Somerville Software engineering 9th edition chapter 25

Thank you

22