Configuration Management
CIS 376
Bruce R. Maxim
UM-Dearborn
Configuration Management
• New versions of software systems are created as
they change
• Configuration management is concerned with
managing evolving systems
• Involves the development of procedures and
standards to manage product evolution
• May be viewed as part of a more general quality
management process
Software Configuration Items
• Computer programs
– both source and executable
• Documentation
– both technical and user
• Data
– within a program or external to it
Fundamental 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
Configuration Management
Standards
• CM should always be based on a set of standards
which are applied within an organization
• Should define how
– items are identified
– changes are controlled
– versions are managed
• Should be based on an evolutionary process model
rather than something like the waterfall model
Baselines
• A work product becomes a baseline only after it is
reviewed and approved.
• A baseline is a milestone in software development
that is marked by the delivery of one or more
configuration items.
• Once a baseline is established each change request
must be evaluated and verified by a formal
procedure before it is processed.
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
Software Configuration Objects
part 1
• 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
Software Configuration Objects
part 2
• Configuration object attributes
–
–
–
–
unique name
description
list of resources
realization (a pointer to a work product for a basic
object or null for an aggregate object)
• An entity-relationship (E-R) diagram
– can be used to show the interrelationships among the
objects
Version Control
• Combines procedures and tools to manage the
different versions of configuration objects created
during the software process
• 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 - part 1
• 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
Change Control - part 2
• Engineering change order (ECO)
– generated for each change approved (describes change,
lists the constraints, and criteria for review and audit)
• 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
Change Control - part 3
• 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
Concurrent Development and
Testing
• Delivery time is agreed upon for system
components
• New system version is built from these
components
• The new version is delivered for testing using
predefined tests
• Detected faults are documented and returned to
system developers
Daily System Builds
• Allows early detection of component interaction
problems
• Encourages developers to do thorough unit testing
• Developers are under pressure not to “break the
build”
• Requires the use of a strict management process to
track problems that are discovered and repaired
Configuration Management Planning
• All products of the software process (including
documents) may have to be managed
• Must start early in project life cycle
• Must define formal documents to be managed
• Documents which are likely to be used for future
system maintenance work should be identified and
specified as managed documents
Configuration Management Plan
• Defines the documents to be managed
• Defines who take responsibility for the
configuration management procedures and
creation of baselines
• Defines policies for change control and version
management
• Defines configuration records to be maintained
• Describes the tools that should be used
Configuration Database
• All configuration management information should
be maintained in a configuration database
• The database should allow queries like
–
–
–
–
Who has a particular software version?
What platform is required for a particular version?
What versions are affected by component X changes?
How many reported faults for version Y?
• The database should be linked to software being
managed (e.g. use of CASE tools)
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?
Change Tracking Tools
• Major problem in change management is tracking
the change status
• Change tracking tools help track the status of each
change request
• Ensures that change requests are sent to the right
people at the right time
• Can be integrated with e-mail systems to allow
electronic distributions of change requests
Derivation History
• Records changes applied to a document or code
component
• Should record
–
–
–
–
change made
rationale for change
who made the change?
when was change implemented?
• May be included as comment in the code
Version Terminology
• Version
– instance of system that is functionally distinct from
other system instances
• Variant
– instance of system that is functionally identical but nonfunctionally distinct from other system instances
• Release
– system instance distributed to users outside the
development team
Version and Release Management
• Invent identification scheme for system versions
– version numbering
– attribute-based identification
– change-oriented identifications
• Plan when new release is to be produced
• Ensure that version management procedures and
tools are applied properly
Version Numbering Derivation Structure
from Sommerville
V1.0
V1.1b
V1.1.1
V1.1
V1.2
V1.1a
V2.0
V2.1
V2.2
Attribute-Based Identification
• Attributes can be associated with a version
–
–
–
–
–
Date
Creator
Programming Language
Customer
Status
• More flexible than explicit name for version retrieval (esp.
database queries)
• Can cause uniqueness problems
• Needs an associated name for easy reference
Change-Oriented Management
• Integrates versions and the changes made to create
each version
• Used for systems rather than components
• Each version has change set that describes the
changes used to implement the version
• Change sets are applied in sequence so that system
versions can be composed by incorporating
arbitrary combinations of changes
System Releases
• Not just a set of executable programs
• May also include
– configuration files used to define system required for a
particular installation
– data files needed for system operation
– installation shields or shells for specific platforms
– electronic and paper documentation
– packaging and publicity information
System Building Problems
• Do the build instructions include all required components?
• Is the appropriate version specified for each build
component?
• Are all data files available?
• Are data file references within components correct?
• Is system being built for the right platform?
• Is the correct versions of the compiler and other tools
specified?