Software configuration management (SCM)

1

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.

2

Sources of Change

New business or market conditions

– dictate changes to SW requirements or business rules

New customer needs

– demand modification of data, functionality, or services

Business reorganization

– causes changes in project priorities or software engineering team

structure

Budgetary or scheduling constraints

– cause system to be redefined

3

Software Configuration Management Tasks

Identification

– tracking multiple versions to enable efficient changes

Version control

– control changes before and after release to customer

Change control

– authority to approve and prioritize changes

Configuration auditing

– ensure changes made properly

Reporting

– tell others about changes made

4

Software Configuration Items

Computer programs

– both source and executable forms

Documentation

– describing the computer programs (targeted at both technical

practitioners users

Data

– contained within the program or external to it

5

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

6

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

objects7

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

8

9

Change Control

Change request

– 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)

– generated for each change approved (describes change, lists

the constraints, and criteria for review and audit)10

Change Control

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 don’t overwrite one another

11

12

CONFIGURATION AUDIT

How can we ensure that the change has been properly

implemented?

Two approaches

– formal technical reviews and the software configuration audit

formal technical review

– focuses on the technical correctness of the configuration object that

has been modified

software configuration audit

– complements the formal technical review by assessing a

configuration object for characteristics that are generally not

considered during review

13

Software Configuration Audit 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?

14

Reporting

Configuration status reporting (sometimes called status

accounting) is an SCM task that answers the following

questions:

– 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

project15

ClearQuest

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.

16

Managing Configurations in Open Source Projects

Version management

– 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,

17

Configuration Selection

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

18

Change management

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

19

Change Process for OSS

20

Release Management

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.

21

Reading

– Pressman Software engineering: a practitioner’s approach Chapter 9

– Somerville Software engineering 9th edition chapter 25

Thank you

22