©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1
Configuration management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 2
Objectives
 To explain the importance of software
configuration management (CM)
 To describe key CM activities namely CM
planning, change management, version
management and system building
 To discuss the use of CASE tools to support
configuration management processes
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3
Topics covered
 Configuration management planning
 Change management
 Version and release management
 System building
 CASE tools for configuration management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 4
 New versions of software systems are
created as they change:
• For different machines/OS;
• Offering different functionality;
• Tailored for particular user requirements.
 Configuration management is concerned
with managing evolving software systems:
• System change is a team activity;
• CM aims to control the costs and effort involved
in making changes to a system.
Configuration management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 5

Configuration management
 Involves the development and application of
procedures and standards to manage an
evolving software product.
 CM may be seen as part of a more general
quality management process.
 When released to CM, software systems are
sometimes called baselines as they are a
starting point for further development.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 6
System families
Server
version
Linux
version
PC version
Initial
system
Desktop
version
Windows XP
version
HP
version
Sun
version
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 7
CM standards
 CM should always be based on a set of standards
which are applied within an organisation.

 Standards should define how items are identified,
how changes are controlled and how new versions
are managed.
 Standards may be based on external CM standards
(e.g. IEEE standard for CM).
 Some existing standards are based on a waterfall
process model - new CM standards are needed for
evolutionary development.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 8
Concurrent development and testing
 A time (say 2pm) for delivery of system
components is agreed.
 A new version of a system is built from these
components by compiling and linking them.
 This new version is delivered for testing
using pre-defined tests.
 Faults that are discovered during testing are
documented and returned to the system
developers.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 9
Frequent system building
 It is easier to find problems that stem from
component interactions early in the process.
 This encourages thorough unit testing -
developers are under pressure not to ‘break
the build’.
 A stringent change management process is
required to keep track of problems that have
been discovered and repaired.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 10

 All products of the software process may
have to be managed:
• Specifications;
• Designs;
• Programs;
• Test data;
• User manuals.
 Thousands of separate documents may be
generated for a large, complex software
system.
Configuration management planning
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 11
 Defines the types of documents to be
managed and a document naming scheme.
 Defines who takes responsibility for the CM
procedures and creation of baselines.
 Defines policies for change control and
version management.
 Defines the CM records which must be
maintained.
The CM plan
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 12
The CM plan
 Describes the tools which should be used to
assist the CM process and any limitations on
their use.
 Defines the process of tool use.
 Defines the CM database used to record
configuration information.
 May include information such as the CM of

external software, process auditing, etc.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 13
 Large projects typically produce thousands of
documents which must be uniquely identified.
 Some of these documents must be maintained for
the lifetime of the software.
 Document naming scheme should be defined
so that related documents have related names.
 A hierarchical scheme with multi-level names is
probably the most flexible approach.
• PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
Configuration item identification
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 14
Configuration hierarchy
PCL-TOOLS
EDIT
STRUCTURES
BIND
FORM
COMPILE MAKE-GEN
HELP
DISP LAY QUERY
AST-INTERFACEFORM-SPECS FORM-IO
CODEOBJECTS TESTS
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 15
 All CM information should be maintained in a
configuration database.
 This should allow queries about configurations to be
answered:
• Who has a particular system version?

• What platform is required for a particular version?
• What versions are affected by a change to component X?
• How many reported faults in version T?
 The CM database should preferably be linked to the
software being managed.
The configuration database
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 16
CM database implementation
 May be part of an integrated environment to
support software development.
• The CM database and the managed documents
are all maintained on the same system
 CASE tools may be integrated with this so
that there is a close relationship between the
CASE tools and the CM tools.
 More commonly, the CM database is
maintained separately as this is cheaper and
more flexible.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 17
 Software systems are subject to continual
change requests:
• From users;
• From developers;
• From market forces.
 Change management is concerned with
keeping track of these changes and ensuring
that they are implemented in the most cost-
effective way.
Change management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 18

Request change by completing a change request form
Analyze change request
if change is validthen
Assess how change might be implemented
Assess change cost
Submit request to change control board
if change is acceptedthen
repeat
make changes to software
submit changed software for quality approval
until software quality is adequate
create new system version
else
reject change request
else
reject change request
The change management process