This document discusses software configuration management (SCM). It defines SCM as coordinating software development to minimize confusion from changes. The key goals of SCM are to maximize productivity by minimizing mistakes through analyzing, recording, reporting, and controlling changes. SCM provides visibility, traceability, and formal control over a software configuration and the evolution of the software. The document outlines the main functions of SCM, including identification, control, auditing, and status reporting of software configuration items and changes. It also discusses sources of change, baselines, issues to consider, and standards for SCM.

1. SCM

2. Introduction
• Change is inevitable when software is built
• Change increases the level of confusion
• Confusion arises when changes are not
–
–
–
–
Analyzed before they are made
Recorded before they are implemented
Reported to those who need to know
Controlled in a manner that will improve
quality and reduce error

3. SCM - 1
• The art of coordinating software development to
minimize confusion is called configuration
management.
• Configuration management is the art of
identifying, organizing, and controlling
modifications to the software being built by a
programming team
• The goal is to maximize productivity by
minimizing mistakes

4. SCM - 2
• Software configuration management is an
umbrella activity, which provides a cover
against
–
–
–
–
–
Lack of visibility
Lack of control
Lack of traceability
Lack of monitoring
Uncontrolled change

5. SCM - 3
• Software configuration management
provides a means for visibility, traceably,
and formally controlling the evolution of
software

6. Software Configuration
• The items that comprise all information
produced as part of the software process are
collectively called a software configuration
– Computer programs (source and executable)
– Documents that describe the computer
programs
– Data
• Software configuration items will grow

7. Change - A Constant
• There is nothing permanent except change
– Heraclitus (500 B.C.)
• 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
• Software is like a sponge due to its
susceptibility to change

8. Sources of Change - 1
• New business or market conditions dictate
changes in product requirements or business
rules
• New customer needs demand modification
of data produced by information systems,
functionality delivered by products, or
services delivered by computer-based
system

9. Sources of Change - 2
• Reorganization or business
growth/downsizing causes changes in
project priorities or software engineering
team structure
• Budgetary or scheduling constraints cause a
redefinition of the system or product

10. Change is Everywhere
• Customers want to modify requirements
• Developers want to modify the technical
approach
• Managers want to modify the project
strategy

11. Why All This Modification?
• As time passes, all constituencies know
more
– About what they need
– Which approach would be best
– How to get it done and still make money
• Statement of the fact: Most changes are
justified!

12. How to Manage Change?
• A baseline is a software configuration
management concept that helps us to
control change without seriously impeding
justifiable change

13. Baseline
• A specification or product that has been
formally reviewed and agreed upon, that
thereafter serves as the basis for further
development, and that can be changed only
through formal change control procedures
– IEEE Std. No. 610.12-1990

14. SCM Functions
• The four software configuration
management functions are
–
–
–
–
Identification
Control
Auditing
Status accounting/reporting

15. SCM Function: Identification
• Each software part is physically labeled,
according to SCM plan

16. SCM Function: Control
• Proposed changes to software parts are
reviewed, then subjected to the agreement
of project participants, and finally
incorporated into the currently approved
software configuration
• Two types of control
– Version control
– Change control

17. Version Control
• Configuration management allows a user to
specify alternative configurations of the
software system through the selection of
appropriate versions. This is supported by
associating attributes with each software
version, and then allowing a configuration
to be specified [and constructed] by
describing the set of attributes

18. Change Control - 1
• Change control is vital
• Too much change control and we create
problems. Too little, and we create other
problems
• The art of progress is to preserve order amid
change and to preserve change amid order
– Alfred North Whitehead

19. Change Control - 2
• For large projects, uncontrolled change
rapidly leads to chaos
• For large projects, change control combines
human procedures and automated tools to
provide a mechanism for the control of
change

20. The Change Control Process - 1
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action
change request is denied
user is informed
Change Control Process—2

21. The Change Control Process - 2
assign people to SCIs
check-out SCIs
make the change
review/audit the change
establish a “baseline” for testing
Change Control Process—3

22. The Change Control Process - 3
perform SQA and testing activities
check-in the changed SCIs
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release

23. Access and Synchronization
Control - 1
• Confusion leads to errors - some of them
very serious
• Access and synchronization control avoid
confusion. Implement them both

24. Access and Synchronization
Control - 2
• Access control governs which software
software engineers have the authority to
access and modify a particular
configuration object
• Synchronization control helps to ensure that
parallel changes, performed by two
different people, don’t overwrite one
another

25. Change Control Issues - 1
• Without proper safeguards, change control
can retard progress and create unnecessary
red tape
• Prior to an SCI becoming a baseline, only
informal change control need be applied
• Once SCI is in a baseline, project level
change control is implemented

26. Change Control Issues - 2
• When the software product is released to
the customer, formal change control is
instituted

27. Change Control Issues - 3
• Change control authority/board assesses the
impact of change beyond the SCI in
question
– How will the change affect hardware?
– How will the change affect performance?
– How will the change modify customer’s
perception of the product?
– How will the change affect product quality and
reliability?

28. SCM Function: Auditing - 1
• How can we ensure that the approved
changes have been implemented?
– Formal technical reviews
• Focus on the technical correctness of the modified
object. The reviewers assess the SCI to determine
consistency with other SCIs, omissions, or potential
side effects
– Auditing

29. SCM Function: Auditing - 2
• Has the change specified in the ECO been
made? Have any additional modifications
been incorporated?
• Has a formal technical review been
conducted to assess technical correctness?
• Has the software process been followed and
have software engineering standards been
properly applied?

30. SCM Function: Auditing - 3
• Has the change been “highlighted” in the
SCI? Have the change date and change
author been specified?
• Have SCM procedures for noting the
change, recording it, and reporting it been
followed?
• Have all related related SCIs been properly
updated?

31. SCM Function: Status
Accounting/Reporting
• The status accounting function provides a
corporate memory of project events that
supports accomplishment of three other
configuration management items
–
–
–
–
What happened?
Who did it?
When did it happen?
What else will be affected?

32. SCM Functions Infuse Visibility
and Traceability - 1
Function
Visibility
Traceability
Identification
•User/buyer/seller can see what
is being/has been built/is to be
modified
•Management can see what is
embodied in a product
•All project participants can
communicate with a common
frame of reference
•Provides pointers to software
parts in software products for use
in referencing
•Make software parts and their
relationships more visible, thus
facilitating the linking of parts in
different representations of the
same product
Control
•Current and planned
configuration generally known
•Management can see impact of
change
•Management has option of
getting involved with technical
detail of project
•Makes baselines and changes to
them manifest, thus providing the
links in a traceability chain
•Provides the forum for avoiding
unwanted excursions and
maintaining convergence with
requirements

33. SCM Functions Infuse Visibility
and Traceability - 2
Function
Auditing
Status Accounting/Reporting
Visibility
Traceability
•Inconsistencies and
discrepencies manifest
•State of product known to
management and product
developers
•Potential problems identified
early
•Checks that parts in one
software product are carried
through to the subsequent
software produc
•Checks that parts in a software
product have antecedents in
requirements documentation
•Reports inform as to status
•Actions/decisions made explicit
(eg., through CCB meeting
minutes)
•Database of events is project
history
•Provides history of what
happened and when
•Provides explicit linkages
between change control forms

34. Real World Considerations - 1
• Management Commitment
– Management commitment to the establishment
of checks and balances is essential to achieving
benefits from SCM
• SCM Staffing
– Initial staffing by a few experienced people
quickly gains the confidence and respect of
other project team members

35. Real World Considerations - 2
• Establishment of a CCB
– As a starting point in instituting SCM, periodic
CCB meetings provide change control,
visibility, and traceability
• CM During the Acceptance Testing Cycle
– CM integrated within the acceptance testing
cycle maintains a visible and traceable product
ready for delivery to the customer

36. Real World Considerations - 3
• Justification and Practicality of Auditing
– Although the auditing consumes the greater
part of the SCM budget, it has the potential of
preventing the waste of much greater resources
• Avoiding the Paperwork Nightmare
– The buyer/user and seller should agree on the
paperwork needed to achieve a mutually
desirable level of visibility and traceability

37. Real World Considerations - 4
• Allocating Resources among CM Activities
– Cost versus benefits must be evaluated for each
individual project in determining the allocation
of limited SCM resources

38. SCM Standards
•
•
•
•
•
•
MIL-STD-483
DOD-STD-480A
MIL-STD-1521A
ANSI/IEEE Std. No. 828-1983
ANSI/IEEE Std. No. 1042-1987
ANSI/IEEE Std. No. 1028-1988

39. Conclusion
• Software configuration management is an
umbrella activity that is applied throughout
the software process
• SCM identifies, controls, audits, and reports
modifications that invariably occur while
software is being developed and after it has
been released
• SCM saves a project from total chaos

40. References
• Software Engineering: A Practitioner’s Approach
by Roger S. Pressman
• A Handbook of Software Quality Assurance
edited by G. Gordon Schulmeyer and James L.
McManus
• Customer-Oriented Software Quality Assurance
by Frank P. Ginac
• Software Quality: Analysis and Guidelines for
Success by Capers Jones