Configuration management
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 1
Software Configuration
Management



Art of coordinating SW development to
minimize confusion
Software quality assurance (umbrella) activity
Set of tracking and control activities beginning
to end
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 2
Why Software Configuration Mgmt?


Change increases confusion
CM necessary when a software system
has
Many developers
 Many versions


CM aims to control the costs and effort
involved in making changes to a system
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 3
Software Configuration Mgmt Activities

Identifying change

Controlling change

Ensuring change is properly implemented

Reporting changes to interested others
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 4
Identifying Changes: Origin of changes





New business or market conditions
New customer needs
Reorganization or business
growth/downsizing
Budgetary or scheduling constraints
Most changes are justified
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 5
Baselines



Concept that helps us control change
without seriously impeding justifiable
change
Before baseline: changes made quickly
and informally
Once baseline established: changes can
be made, but a formal procedure must be
applied to evaluate and verify each change
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 6
Identifying Changes

SW Configuration Items (SCIs) are
identified
•
•
Document, suite of test cases, program
component, software tools
Identify relationships among SCIs (partof, interrelated, dependencies)
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 7
Controlling Changes

Version control
•
•
manage many existing versions of SCIs
Use evolution graph or object pool
representation
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 8
Controlling Changes
•
•
•
•
•
•
•
•
•
•
before and after release
Authority (access control and synchronization
control)
Change requests submitted and evaluated
Change report (results of evaluation)
Change order (for approved change)
Check out SCI, make change, apply SQA activities
Check in SCI to database and version control
mechanisms
Before baseline, informal change control
Once baseline est. project level change control
After release, formal change control
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 9
Ensure change properly implemented

aka Configuration auditing
•
•
Formal technical reviews
Software configuration audit
•
•
•
•
Change made? Additional modifications?
Formal technical review conducted?
Software process followed/standards applied?
Change “highlighted” in SCI? change
date/author noted?
• SCM procedures followed?
• Related SCIs updated?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 10
Reporting Changes
•
•
•
•
What happened?
Who did it?
When?
What else will be affected?
•
Keep management and practitioners
appraised of important changes.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 29
Slide 11