Software
Software Configuration
Configuration
Management
Management (SCM)
(SCM)
Overview
What is SCM?
What are the processes of SCM?
How does each process do?
Summary
Software
Software Configurations
Configurations
Software configuration -- the output
Computer programs (source and executables)
Documents
Data
Software Configuration Management (SCM)
The art of identifying, organizing and controlling
modifications to the software being built
Why
Why Do
Do We
We Need
Need SCM?
SCM?
First Law of System Engineering
No matter where you are in the system life
cycle, the system will change and the desire to
change it will persist throughout the life cycle
Sources of Change
New business or market conditions
new customer needs
Organization and/or business downsizing
Budgetary or scheduling constraints
Baseline Concept
IEEE defines a baseline as:
A specification or product that has been formally
reviewed and agreed upon, that thereafter serve as the
basis for further development, and that can be changed
only through formal change control procedures
A baseline is a milestone in the development of
software that marked the delivery of one or more
software configuration items
Common Baselines
System engineering
System specification
Requirement analysis
Software requirement
Software design specification
Design specification
Coding
Source code
Testing
Test plans/Procedures/Data
Release
Operational system
Software Configuration Item (SCI)
Information created as part of SE process
SCIs used as target in SCM:
System specification
Software project plan
Software requirements specification
Preliminary user manual
Design specification
Source code listing
SCI (Cont’d)
Test specification
Operation and installation manuals
Executable program
Database description
As-built user manual
Maintenance documents
Standards and procedures for SE
SCI Modification Process
SCM Process
Identification
Version control
Change control
Configuration auditing
Status reporting
Object identification in SW configuration
SCI can be named and organized using OO
approach
Two types of objects:
basic object: ‘unit of text’ created during
analysis, design, coding, or testing.
Aggregated objects: a collect of basic objects
Object identification in SW
configuration (cont’d)
Features of objects:
name: a character string
description: a list of data items to identify the SCI
type and a project id, version information, etc.
resources: entity that are provided, processed,
referenced by the object
Realization: a pointer to ‘unit of text’ for a basic
object or null for an aggregate object
Object identification in SW
configuration (cont’d)
Relationships between objects
part-of: a hierarchical relationship
interrelated: a cross-structural relationship
Object identification methods
evolution graph
automated SCM tools
module interconnection language
Configuration
Configuration Objects
Objects
Evolution Graph
obj obj
1.3 1.4
obj obj obj
1.0 1.1 1.2
obj obj
2.0 2.1
obj obj
1.1.1 1.1.2
Version Control
Some of the issues
When an executable is built, the versions of its
constituents must be consistent.
If A depends upon B and B is recompiled, A may
also need to be recompiled.
What if multiple people need to modify same SCI?
Need to know what version different customers have
How do you keep track of 100’s or 1000’s of
modules?
Version
Version Control
Control
Evolution graph to represent different
versions
Uses an object pool representing components,
variants and versions, and their relationship
RCS (Revision Control System) is common
tool.
Use for documentation as well as code
development.
Version
Version Control
Control Support
Support
At the language level (in Ada):
With B;
Spec A Spec B
Body A Body B
If only body of B changes, no change to A
If spec of B changes, A must be recompiled
Change Control
Change request from user
Developer evaluates
Change report is generated
Change control authority makes decision
Request is queued, Change request is denied
persons are assigned
User is informed
“Check out” SCI(s)
Change Control (cont’d)
Make the change/review change
‘Check in’ changed SCIs
Establish a baseline for testing
Do SQA and ‘promote’ changes for inclusion in next
release
Rebuild appropriate version
Audit the SCI changes/ include changes in new version
Release the new version
Access and Synchronization Control
Configuration Audit
Two approaches can be used to ensure proper
implementation of change:
formal technical review
software configuration audit
CA assesses a configuration object for characteristics that
are not generally not considered during review
CA generally checks:
•Changes incorporated •SCM procedures followed
•FTR conducted •all related SCIs properly updated
•SE standards followed •change date and author specified
Status Reporting
Event occurred -- An SCI received updated ID
people involved
Time happened
Effects on others
Generated on a regular basis
To improve communication among all parties
Summary
SCM identifies, controls, audits and reports
modifications
An object becomes a baseline once developed
and reviewed
Version control is the set of procedures and
tools for managing the use of these objects
Summary
Summary
Change control is a procedure activity
necessary to achieve quality and consistency
Configuration audit is an SQA activity to
help ensure quality is maintained
Reporting provides information for better
communication
