Configuration management

Managing the products (code
and documentation) of system
as it changes
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 1
Configuration management

New versions of software systems are created
•
•
•
•

Enhancements / Fixes
Different stages of development
For different machines/OS
Less likely, tailored for particular user requirements, offering
different functionality
Configuration management is concerned with
managing evolving software systems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 4
Configuration management



Involves the development and application of
procedures and standards to manage an evolving
software product
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 2000
Software Engineering, 6th edition. Chapter 29
Slide 5
System families
PC
version
VM S
version
Initial
system
DEC
version
Mainframe
version
Workstation
version
Unix
version
Sun
version
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 6
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)
Existing standards are based on a waterfall
process model - new standards are needed for
evolutionary development
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 7
CM for evolutionary development
(Concurrent development and testing)




A time 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 2000
Software Engineering, 6th edition. Chapter 29
Slide 8
Daily system building




It is easier to find problems that stem from
component interactions early in the process
Encourages thorough unit testing - developers are
under pressure not to ‘break the build’
Successful use requires stringent change
management process to keep track of problems
that have been discovered and repaired
Produces many versions that must be managed
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 9
29. 1 Configuration management
planning

All products of the software process may have
to be managed
•
•
•
•
•

Specifications
Designs
Programs
Test data
User manuals
Thousands of separate documents are generated for a
large software system
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 10
CM planning



Starts during the early phases of the project
Must define the documents or document
classes which are to be managed
Documents which might be required for future
system maintenance should be identified and
specified as managed documents
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 11
The CM plan





Types of documents to be managed
Who takes responsibility for CM
Policies for change control and version management
CM records which must be maintained
…
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 12
The CM plan



Tools for CM
CM database used to record configuration
information
Other …
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 13
Configuration item identification




Large projects produce thousands of documents
Some must be maintained for the software lifetime
Document naming scheme needed
Hierarchical scheme with multi-level names
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 14
Configuration hierarchy
PCL-TOOLS
COMPILE
FORM-S PECS
EDIT
MAKE-GEN
FORM
STRUC TUR ES
HELP
DIS PLAY
QUERY
AS T-INTERFACE
FORM-IO
OB JECTS
©Ian Sommerville 2000
BIND
CODE
TESTS
Software Engineering, 6th edition. Chapter 29
Slide 15
The configuration database


All CM information should be maintained in a
configuration database
This should allow queries about configurations to be
answered
•
•
•
•
•

What customers have a particular system version?
What platform is required for a particular version?
How many versions have been created?
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
version management system for software being managed
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 16
29.2 Change management

Software systems are subject to continual
change requests
•
•
•


From users
From developers
From market forces
Change management is concerned with keeping
managing of these changes and ensuring that
they are implemented in the most cost-effective
way
Change management starts when materials put into
configuration management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 18
The change management process
Request change by completing a change request form
Analyze change request
if change is valid then
Assess how change might be implemented
Assess change cost
Submit request to change control board
if change is accepted then
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 19
Change request form



Definition of change request form is part of the
CM planning process
Records change required, suggestor of change,
reason why change was suggested and
urgency of change(from requestor of the
change)
Records change evaluation, impact analysis,
change cost and recommendations (System
maintenance staff)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 20
Example Change request form
Change Request Form
Project: Proteus/PCL-Tools
Number: 23/94
Change requester: I. Sommerville
Date: 1/12/98
Requested change: When a component is selected from the structure,
display the name of the file where it is stored.
Change analyser: G. Dean
Analysis date: 10/12/98
Components affected: Display-Icon.Select, Display-Icon.Display
Associated components: FileTable
Change assessment: Relatively simple to implement as a file name table
is available. Requires the design and implementation of a display field. No
changes to associated components are required.
Change priority: Low
Change implementation:
Estimated effort: 0.5 days
Date to CCB: 15/12/98
CCB decision date: 1/2/99
CCB decision: Accept change. Change to be implemented in Release 2.1.
Change implementor:
Date of change:
QA decision
Date submi tted to QA:
Date submitted to CM:
Commen ts
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 21
Change tracking tools




A major problem in change management is
tracking change status
Change tracking tools keep track the status of
each change request and automatically ensure
that change requests are sent to the right
people at the right time.
Integrated with E-mail systems allowing
electronic change request distribution
May be integrated with Configuration Management DB
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 23
Change control board



Decide based on a cost, strategic and organizational
viewpoint
Should be independent of project team
Representatives from client and contractor staff
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 24
Derivation history




Record of changes applied to a document or
code component
Should record, in outline, the change made, the
rationale for the change, who made the change and
when it was implemented
Impact in tracked item should be marked
May be included as a comment in code. If a standard
prologue style is used for the derivation history, tools
can process this automatically
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 25
Component header information
// PROTEUS project (ESPRIT 6 087)
//
// PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE
//
// Object: PCL-Tool-Desc
// Author: G. Dean
// Creation date: 10th November 1998
//
// © Lancaster University 1998
//
// Modification history
// Version
Modifier Date
Change
Reason
// 1.0
J. Jones
1/12/1998
Add header Submitted to CM
// 1.1
G. Dean
9/4/1999 New field Change req. R07/99
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 26
29.3 Version and release management




Invent identification scheme for system
versions
Plan when new system version is to be
produced
Ensure that version management procedures and
tools are properly applied
Plan and distribute new system releases
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 27
Version identification


Procedures for version identification should
define an unambiguous way of identifying
component versions
Three basic techniques for component
identification
•
•
•
Version numbering
Attribute-based identification
Change-oriented identification
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 29
Version numbering




Simple naming scheme uses a linear derivation
e.g. V1, V1.1, V1.2, V2.1, V2.2 etc.
However, actual derivation structure may be a
tree or a network rather than a sequence
Names are not meaningful.
Hierarchical naming scheme may be better
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 30
Version derivation structure
V1.0
V1.1b
V1.1.1
V1.1
V1.2
V2.0
V2.1
V2.2
V1.1a
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 31
Attribute-based identification






Attributes can be associated with a version with
the combination of attributes identifying that
version
Examples of attributes are Date, Creator,
Programming Language, Customer, Status etc.
More flexible than an explicit naming scheme
for version retrieval;
Supports queries when looking for versions
Can cause problems with uniqueness
Awkward - needs an associated name for easy reference
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 32
System releases


Not just a set of executable programs
May also include
•
•
•
•
•

Configuration files defining how the release is configured for a
particular installation
Data files needed for system operation
An installation program or shell script to install the system on
target hardware
Electronic and paper documentation
Packaging and associated publicity
Systems are now normally released on CD-ROM
or as downloadable installation files from the web
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 36
Release problems
• Release management must not assume that all
previous releases have been accepted.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 37
Release decision making



Must plan when to distribute a system release
Preparing and distributing a release is expensive
Factors:
•
•
•
technical quality
competition, marketing requirements
customer change requests
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 38
Release creation



Collect all files and documentation
Configuration descriptions / instructions/ scripts
Documented to allow re-creation
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 40
29.4 System building



The process of compiling and linking software
components into an executable system
Different systems are built from different
combinations of components
Invariably supported by automated tools that are
driven by ‘build scripts’
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 41
System building
System
builder
Build
script
©Ian Sommerville 2000
Version
management
system
Source code
component
versions
Compilers
Linker
Object code
components
Software Engineering, 6th edition. Chapter 29
Executable
system
Slide 42
System building problems



Do the build instructions include all required
components?
Is the appropriate component version
specified?
Are all data files available?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 43
System building problems



Are data file references within components
correct?
Is the system being built for the right platform
Is the right version of the compiler and other
software tools specified?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 44
29.5 CASE tools for configuration
management




CM processes are standardized and involve
applying pre-defined procedures
Large amounts of data must be managed
CASE tool support for CM is therefore essential
Mature CASE tools to support configuration
management are available ranging from standalone tools to integrated CM workbenches
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 46
Change management tools


Change management is a procedural process so it can be
modelled and integrated with a version management
system
Change management tools
•
•
•
Form editor
Workflow system
Change database, with query facilities
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 47
Version management tools




Version and release identification
Storage management.
Change history recording
Independent development
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 48
Delta-based versioning
Version
1.0
Version
1.1
D1
Version
1.2
D2
Version
1.3
D3
Creation date
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 49
e.g. Microsoft Visual Source Safe


Part of Visual Studio
Handles Sharing of Files in a project
•
•

Handles Multiple Versions
•
•

Check out for making changes
Check back in after changes
Saves latest
Saves “Backward Deltas”
Mostly makes sense with network common area
available to whole team
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 50
Microsoft Visual Source Safe





VSS keeps a database
Inside DB there are Projects
Projects include files
Users have working folder for when they are
working on something
Shadow Folder – common, read only versions of
current code
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 51
Microsoft Visual Source Safe








Check out file – copied to your working folder
While checked out, other check-outs are stopped
Check back in makes file available to others
If not changing file, can Get / View the file (read only)
Can cancel checkout if decide not to change file
VSS can show differences between versions of a file
VSS keeps track of versions using numbers, by date, AND
by user-defined labels (names)
Can try to merge different versions of a file
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 52
System building



Building a large system is computationally
expensive and may take several hours
Hundreds of files may be involved
System building tools may provide
• A dependency specification language and
interpreter
• Tool selection and instantiation support
• Distributed compilation
• Derived object management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 53
Component dependencies
comp
scan.o
syn.o
sem.o
cgen.o
scan.c
syn.c
sem.c
cgen.c
defs.h
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 29
Slide 54