2. Contents
Characteristics of Today’s Software industry
SCM Concepts and terminology
Why Software configuration management?
Requirements of Configuration management
Standard reports
Typical Uses of SCM
3. The Fundamental Law of
Configuration Management
Configuration Management is the
foundation of a software project.
Without it, no matter how talented
the staff, how large the budget,
how robust the development and
test processes, or how technically
superior the development tools,
project discipline will collapse and
success will be left to chance. Do
Configuration Management right,
or forget about improving your
development process.
4. Why did the Tower of Babel fail?
The Tower of Babel project failed
because of lack of communication
and organization
6. Characteristic 1 -
Coordination & Communication
Men and months cannot be interchanged
Fred Brooks
• Number of communication channels
increase exponentially with number of
team members - the number of
coordination problems also increase
exponentially with the project size.
10. Characteristic 3 -
Changes
• Different users / customers have different
requirements
• Get clarified / known at a later date
• Changes to business environment
• Technology change
• Personnel whims
11. Characteristic 4 -
Personnel Turnover
• Developers leave
• Users change
Further Adds to the Coordination problem
12. Resulting Problems
• Listing seems OK; program does not work
• Works in Bombay, misbehaves in Delhi
• We had customized for this client, how do we
install the upgrade now?
• I had fixed this bug last month. How did it re-
appear?
• I haven’t changed the program. Why is it now
blowing up?
• Which is the latest source? I need to put a
patch.
• In the last month, the user asked for this change
and now she does not want it
• Where did Gates leave the programs he was
working on?
13. Main Classes of Problems
• Double maintenance problems
• Shared data
• Simultaneous update
• Missing / unknown version problem
14. Double Maintenance
• Multiple copies of same software in use
• Fix in one
- SHOULD FIX IN OTHERS
• Example
- Same set of common routines in two systems
- Same system - multiple sites
• forget to inform
• sites detect bug at same time and “fix”
differently
• = = > > DIVERGENCE
• Should do
- Bug fixed in all copies
- Fix same bug in identical manner in all copies
15. Shared Data
• Changes made in one program interfere with proper
functioning of other program
- Example : subroutines, MW objects
• Need
- Control of modifications
- Good communications
16. Simultaneous Update
• One module being worked on by more than one
programmer
- Changes made by one programmer disappear
• Need
- Better division into modules
- Ensure simultaneous working
17. Missing / unknown Version
problem
• Consciously decide which version to keep, which to
destroy
• Use a systematic method to identify versions and
changes across versions
• Use consistent back-up procedures
?
19. SCM provides visibility into the status of the
evolving software product.
SCM answers the following: Who, What,
When, and Why.
• Who made the changes?
• What changes were made to the software?
• When were the changes made?
• Why were the changes made?
Who will benefit from SCM(Importance in
descending order) :
• Software developers
• Project managers
• Quality Assurance (QA) personnel
• Testers
• Customer
23. Definitions
The arrangement of a computer system or
component as defined by the number,
nature, and interconnections of its
constituent parts
Configuration
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.
Configuration Management
25. Configuration Identification
The approved documentation or description
that identifies and defines a configuration
item's (CI) functional and physical
characteristics in the form of a specification
or standard, algorithm or code, and interface
control description.
A
B
C
D
26. Configuration Control
• Evaluation, coordination, approval or disapproval,
and implementation of changes to configuration
items after formal establishment of their
configuration identification
27. Configuration Status Accounting
• Recording and reporting of information needed to
manage a configuration effectively. Includes a
listing of the approved configuration
identification, the status of the proposed changes
to the configuration identification, and the
implementation status of approved changes.
CI = 30
CR = 2
PR = 1
28. Configuration Audit
• Verifying the following:
•All required configuration items have been
produced
•The current version agrees with the specified
requirements
•The technical documentation completely and
accurately describes that configuration items
•All change requests have been resolved
30. CM Requirements
• Identification of Configuration Items
• Establishment of Baselines
• Document control
• Version control
• Management of Workspaces
• Creation of Builds
• Backup & Archival
• Management of Changes to Baselined
Configuration Items
• Status Accounting
• Configuration Audits
31. Configuration Items and Baselines
• Configuration Item
- An aggregation of software, documents
and data that is treated as a single entity
in the configuration management process
There are 3 types of CIs:
Baselined – Formally reviewed and agreed
document/source code, which is basis
for, further development. E.g.
Requirement specification document,
design document etc.
Controlled and Managed – Documents
describing the admin and project
Management activities. E.g. Project
management plan, task allocation and
project schedule documents, coding or
GUI guidelines
Controlled – Documents obtained from
the customer which are not managed by
us. E.g. reference technical material.
32. • What is Baseline?
- A item 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
procedures
33. Configuration Items & Baselines -
Typical Scenario
• Definition Baseline - Created at the end of
Requirement Specifications. Typical
configuration items (CI) -
- Requirement Specifications
- Project Plan
- Design Standards / Guidelines
- Acceptance Test Plan
• Design Baseline - Created at the end of
Design. Typical CIs -
- System Design Specification
- Program Specification
- Data Base Design
- Coding Standards
- System Test Plan
- User Manual
- User Interface Standards
- Testing Standards
34. • Code / Unit Test Baseline - Created at the
end of coding and unit. Typical
configuration items (CI) -
- source code
- object code
- unit test data / scripts
• Testing Baseline - Created at the end of
system testing . Typical CIs -
- System test data
- system test scripts
- operations manual
- installation manual
36. Document control
• Document Control procedure ensures the
traceability of all the documents.
It involves the following tasks:
• Defining the naming scheme.
• Updating Document Record List (DCR) of
the documents to reflect the changes and
assigning of version and release nos.
• Provides usage of the documents by giving
access rights to different folders.
MyName is
Mr.Unique
37. Version
• A variant of some artifact; later
versions of an artifact typically expand
on earlier versions.
Version Control
• Version Control ensures the ability to
reproduce any version of the software
at any given time. It controls versions
of source code, executables and
documents .It provides version change
history to ensure trace-ability.
A1
A2
A3A4
38. An operational version of a system or
part of a system that demonstrates a
subset of the capabilities to be
provided in the final product.
39. Work space management
• Workspaces refer to ‘private’ areas
where developers can implement and
test code in accordance with the
project’s adopted standards in relative
isolation from other developers.
42. I can make the change directly in the
baseline copy. Its just a one line
change, so I don’t want to fool
around with Change Request, check-
out, check-in, etc
43. Change Control
• Record of changes
• Approval of change requests after analysing
impacts (impact on retest & review, think it
as another proposed)
• Maintaining of baselines
• Traceability between changes and change
requests and vice versa
IEEE Definition
An element of configuration management,
consisting of the evaluation, coordination,
approval or disapproval, and implementation of
changes to configuration items after formal
establishment of their configuration
identification
44. Change Management Process
Change request documented
Change request Evaluated
Change request reviewed for approval CCB
approved
Change order prepared
Configuration items, tasks, QC required is
documented
Configuration items checked out
Change made; QC activities carried out
Configuration audit carried out
Changed items carried out
New product release made
Pending rejected
45. Change Request
XYZ Software Corp. Change Request
Project: Initiated By: Date:
Description of Change Requested:
Benefits Expected:
Signature of Initiator: Attachments:
Evaluated by: Change Request No.
Technical Impacts:
Estimates for costs and schedule
Signature of evaluator: Attachments
Date:
Approving Auth Signature Date
Recommendations
Change Order Number
46.
47. Change Control Board
(CCB)
• Also called Configuration Control Board
• A group of people responsible for evaluating
and approving and disapproving proposed
changes to configuration items, and for
implementation of approved changes.
• Typical CCB members
- Project Manager
- User Representative
- Quality Controller
- Configuration Controller
48. Some Good Practices
• Keep version history in the configuration
item.
• Item to contain exact item name, version
number, date
• Identify configuration items to be tracked
• Code should have history in the comment
• Highlight the changes in the document
atleast for two versions.
50. Configuration Audits
• To ensure that what has been built is in
conformance with what was required
(original specifications and change requests)
by analysing :
- Test reports
- review reports
- change logs
Definition
Verification of a configuration item’s
compliance with its configuration identification
52. Configuration Status
Accounting & Reporting
• Keep track of
- Current identification of items
- Configuration of delivered software
- Status of change requests / problem
reports
- Status of approved changes
IEEE Definition
An element of configuration management,
consisting of the recording and reporting of
information needed to manage a configuration
effectively
53. Typical Information
Baseline Library
Items /
Units
Baseline
Units
Release
Release
Units
Change OrderBackup
Backup
Units
Check-in /
Check-out
Change Request/
Problem Log
54. Standard Reports
• Summary list Change Requests / Problem
Reports
• List of CR / PR pending approval
• Summary list of Change Orders
• List of Change Orders pending completion
• Items and versions of a Baseline
• Current set of units in the library
• List of changes since Baseline
• List of checked-out items
• History of backups
• History of releases
• List of items / versions in a baseline
• List of items / version in a release
55. Typical Uses of the
Configuration Accounting
Data
• In which backup is version 1.6 of P13?
• What are the program level changes between
release 5.1 and 5.2?
• Which programs were replaced in release
5.2?
• Which items were changed for Change Order
671? What were the versions of the units
before and after the change? Have all the
changes been incorporated and checked-in?
![Software Configuration
Management
(SCM)
[1.0]
VOYAGER
L&T Information
Technology Ltd.](https://image.slidesharecdn.com/voyagerscm-101119032748-phpapp01/85/Voyager-scm-1-320.jpg)
