Principles and Practices (Msc in Software Engineering program 2002)

1. Software Configuration Management
Principles and Practices
By Guy Davis,
Stephane Saleh and Kejin Huang

2. Abstract
The concept (Kejin)

 Basic principles (Guy)
 SCM Automation and Tools (Stephane)
 SCM in the Future (Stephane)
 Tools comparison (Kejin)

3. Introduction
Configuration Management(CM) is a
documentation system for tracking the
work.

4. History
1980, Bersoff, E. H., Henderson, V.D., and

Siegel, S. G. Software Configuration
Management. Prentice-Hall.
1984, The British Standard BS 6488

1987, IEEE Guide to Software Configuration

Management 1987. IEEE/ANSI Standard
1042-1987.
1987, U. S. Department of Defense. DoD

2167a Standard 1987. DoD.

5. Why SCM is needed
The project body

The project may be big. When a change is made in a shared
component, the user may not be notified. (The change may be a bug
fix or an improvement.)
The time

The development progress steps may last long. When the versions
become a tree, the bugs could appear or disappear in different nodes.
The people

A lot of people may be involved. A simultaneous update may destroy
the others’ work.

6. The goal (why)
To have change activity converge

Controlling ad-hoc change creates a stable

software development environment
Control of change is a major part of baseline

management
SCM co-ordinates access to change of the

software work products which is particularly
important when there is more than one
individual work on a software work product

7. Concept
“Configuration management involves the collection

and maintenance of data concerning the hardware
and software of computer systems that are being
used.” [SIMON & DENNIS - Ref 1]
“CM embodies a set of techniques used to help

define, communicate and control the evolution of a
product or system through its concept, development,
implementation and maintenance
phases.” [SWEETMAN - Ref 2]
“CM, a key concept in the Information Age, is a set of

systematic controls to keep information up to date
and accurate.” [MORRIS - Ref 3]

8. Concept (cont’d)
“A discipline applying technical and

administrative direction and surveillance
to. …” (IEEE)
 “A collection of hardware, software,
and/or firmware, which satisfies an end-
use function and is designated for
configuration management.quot; (ISO)

9. What is not
Just version management

 Just change management
 Just a build-and-release tool
 An administration tool

10. The Scope

11. Principles of SCM
 Configuration Identification
– Baselines
 Change Control
 Configuration Status Accounting
 Configuration Audits and Reviews
– SCM metrics

12. Configuration Identification
 SCM Planning document
– Objectives, responsibilities, and methods
 Identify configuration items:
– Independent components of the system
 Logical configuration hierarchy
– Object-based view
– Directory-based view

13. Baselines
 Complete status of a CI at a given time
 Know quality and functionality
 Unchangeable and able to recreate
Mozilla SCM Roadmap

14. Change Control
 Control change between baselines
 Various levels of control
– Open policy (no control, just tracking)
– Informal code review by module owner
– Change Control Board (CCB)
 Tailor level to organization and project

15. Configuration Status
Accounting
 Monitor status of CIs and change
requests
– Complete listing of all changes since last baseline
(including who, what, when)
– Ideally changes should be traceable to rationale
 Allows tracking of progress to next
baseline
 Allows for previous releases/versions to
be extracted for testing

16. Configuration Audits
and Reviews
 Validation of completeness and consistency
 SCM audits occur during project transitions
– Requirements, design, implementation, test, …
 Ensures that SCM plan is being followed
 Useful to review SCM metrics gathered
 Feedback allows process improvement

17. Implementation Issues
Requires champions, sponsors, agents

 Requires planning (SCMP)
 Requires training and documentation
 Requires maintenance
 Can be measured and improved

18. SCM Automation
 Why Automation?
- Difficult to manage developments
by large teams operating at different
remote sites
- Projects are becoming bigger and more
complex

19. SCM Automation (cont’d)
(A. Brown, S. Dart, P. Feiler, K. Wallnau, 1991)

20. SCM Automation (cont’d)
 Components Concepts
- Component concepts help identify and access
components of a software product.
- Requirements covered: version control,
configuration, repository, etc.
- Example of tools or systems: Revision Control
System (RCS), Sherpa Design Management
System (DMS)

21. SCM Automation (cont’d)
 Structure and Construction Concepts
- Concepts that deal with capturing changes to
a component and its structure.
- Requirements covered: building, optimizing ,
recording information to allow regeneration of
components, etc.
- Example of tools or systems: Aide-De-Camp
(ADC), Jasmine system model, Rational…

22. SCM Automation (cont’d)
 Team Concepts
- Concepts that help with the co-ordination and
synchronization of software engineering
teams working on a project.
- Requirements covered: work areas for
isolating work, synchronizing, concurrent
work…
- Example of tools or systems : Shape,
Software Management System (SMS),
Network Software Environment (NSE)

23. SCM Automation (cont’d)
 Process Concepts
- Concepts that are related to process
functionalities.
- Requirements covered: lifecycle support, task
management, communication and
automatically recording information.
- Example of tools or systems : PowerFrame,
ISTAR, LIFESPAN, Change and Configuration
Control (CCC)

24. Tool Class 1
Code or Developer oriented CM tools only
supply the code management, version
control, including check-in, check-out,
merge, etc.

25. Tool Class 2
 Process oriented CM tools also supply management
for software development activities. It may cover:
 Version Control
 Change Control
 Product Management
 Problem Tracking
 Activity Tracking
 Build Management
 Document Management
 Requirements Tracking.

26. SCM Challenges
• Technological Issues
• Process-Oriented Issues
• Managerial Issues
• Political Issues
• Standardization Issues

27. SCM Challenges (cont’d)
• Technological Issues
- Switching CM Capabilities
- Interoperability between CM
- Global Perspective on CM
- Repositories
- Distributed CM
- Perfective Maintenance Support

28. SCM Challenges (cont’d)
• Process-oriented Issues
• Political Issues
• Standardization Issues

29. Q/A

30. Tool Index (cont’d)
 FtpVC http://www.nisnevich.com/ftpvc/ftpvc.htm.
 PERFORCE http://www.perforce.com/
 PVCS http://www.merant.com/
 QEF http://www.qef.com/
 QVCS http://www.qumasoft.com/.
 RAZOR http://www.razor.visible.com/
 SABLIME http://www.bell-labs.com/project/sablime
 Software Manager (MKS) http://www.verticalsky.com/solutions/
 Source Code Manager http://www.unipress.com/free_evals/
 StarTeam http://www.starbase.com/.
 TeamConnection (IBM) http://www.software.ibm.com/ad/teamcon/
 TLIB http://www.burtonsys.com/.
 CVS http://www.cvshome.org/

31. Comparison
+1CM AccuRev AllChange CCC Change Man ClearCase
Client/server
    
Graphical GUI
    
Basic CM
    
commands
Baselines
    
Report
 
Auto-make
  
Integration
   
with other
tools
Life-cycle
 
support
Tool Class 1 2 2 2 2 1

32. Comparison (cont’d)
CM Synergy CMF Code Co-op CMVS CMZ CONTROL-
CS
Client/server      
Graphical GUI

Basic CM

commands
Baselines
    
Report

Auto-make

Integration
 
with other tools
Life-cycle

support
Class Tool 2 2 1 2 1 1

33. Comparison (cont’d)
DSM eChange FtpVC NeumaC PerFORCE PVCS
Man M+
Client/server      
Graphical GUI
Basic CM Half
    
commands
Baselines      
Report
Auto-make
  
Integration with
   
other tools
Life-cycle support

Class Tool 2 2 1 2 1 1

34. Comparison (cont’d)
QEF QVCS RAZOR SABLI Software Source Code
ME Manager Manager
Client/server      
Graphical GUI   
Basic CM     
commands
Baselines      
Report   
Auto-make 
Integration with   
other tools
Life-cycle  
support
Class Tool 2 1 2 2 2 2

35. Comparison (cont’d)
StarTeam TeamConne TeamW TLIB TRUEchange
ction are
Client/server     
Graphical GUI  
Basic CM     
commands
Baselines     
Report
Auto-build 
Integration with PVCS
other tools SourceSafe
MsProject
Life-cycle
support
Class Tool 2 2 2 1 1

36. Comparison (cont’d)
VisualEnabler Visual MainSoft Voodoo CVS
SourceSafe VSS
Client/server     
Graphical GUI     
Basic CM     
commands
Baselines     
Report
Auto-build 
Integration with   
other tools VisualStudio Cervisia,
WinCVS
Life-cycle
support
1 1 1 1 1
Class Tool

37. References
A. Brown, S. Dart, P. Feiler, K. Wallnau. The State of Automated Configuration

Management, Software Engineering Institute. Carnegie Mellon University. 1991.
http://www.sei.cmu.edu/legacy/scm/abstracts/absatr_cm_state.html
Berlack, R.H. Evaluation & Selection of Automated Configuration Management

Tools. 1995. http://www.stsc.hill.af.mil/crosstalk/1995/nov/evaluati.asp
Dart, Susan. Concepts in Configuration Management. Software Engineering Institute.

Carnegie Mellon University. 1991. http://www.sei.cmu.edu/legacy/scm/abstracts/
abscm_concepts.html
Eich, Brendan. Mozilla Tree Management Roadmap. Mozilla Organization. 2002. http://

www.mozilla.org/roadmap.html
Humphrey, Watts S. Managing the Software Process. Addison-Wesley Publishing

Company. Reading, Massachusetts. 1990
Kelly, Marion. Configuration Management: The Changing Image McGraw-Hill U.K.,

1996.
Menks, D. Software Configuration Management. University Of Calgary. 2001.

http://www.ucalgary.ca/~dbmenks/seng/seng621/scm.html