SQM – Session 3

Software Configuration
Management
 Objectives
 What is Software Configuration Management
 Illustrate the need for Software Configuration
Management
 Present predicted results from implementing
Software Configuration Management
 Provide a brief description of the key SCM
activities and concepts
 SCM Tools
 SCM
• Configuration
The arrangement of a computer system of component as defined by the number,
nature, and interconnections of its constituent parts
• Configuration Management
A discipline applying technical and administrative direction and surveillance to:
identify and document the functional and physical characteristics of a
configuration item, and control changes to those characteristics,report change
processing and implementation status, and verify compliance with specified
requirements
 Need for SCM
 Number of communication channels increase
exponentially with number of team members-the
number of coordination problems also increase
exponentially with the project size.
 Software is Easy to Copy
 Changes
 Staff Turnover
 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 reappear
 I haven’t changed the program. Why is it now
blowing up?
 Which is the latest source ? I need to put a patch.
 Resulting Problems -2
 In the last month, user asked for this change and
now she does not want it
 Where did Anil leave the programs he was
working Where did Anil leave the programs he
was working on?
 Software Configuration
Management
 SCM addresses all the issues!!
 Key SCM activities
• Configuration Identification
Selection of the configuration items for a system and recording their
functional and physical characteristics
• Baselining
A item that has been formally reviewed and agreed upon, that thereafter
serves as the basis further development, and that can be changed only
through formal change procedures
• Change Control
Evaluation,coordination, approval or disapproval, and implementation of
changes to configuration items after formal establishment of their
configuration identification.
 Key SCM activities - 2
• 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 configuration, and
the implementation status of approved changes.
• Configuration Audit
Verifying that all required configuration items have been
produced, that the current version agrees with the specified
requirements, that the technical documentation completely and
accurately describes the configuration items and that all
change requests have been resolved.
 Key SCM activities - 3
• Subcontractor Control (If applicable)
Evaluation,coordination and approval or disapproval
of all changes submitted by the subcontractor to
approved configuration documentation and
monitoring of the subcontractor’s performance on CM
function.
Configuration Identification
 Configuration Identification
 Identifying the structure of the software system
 Identifying all related software life cycle work
products
 providing a unique identifier for each of those
work products
 Supporting traceability between the software and all
other related software products.
 Configuration Identification
• An organisation and/or project should identify
which work product are to be placed under
configuration Management
• The criteria for which items are selected should
be documented and made available to all
affected groups that are supporting the software
project
 Examples of
•
Configuration items
Examples of work products that may be identified to be placed under
configuration control include:
• Requirement specification compilers
• development plan operating systems
• architecture specification Linkers/Loaders
• Interface specifications procedure languages
• design specification shell scripts
• code modules other related support tools
• Test plans third party tools
• test procedures project plans
• user documentation quality plans
• development procedures configuration management plans
• standards logical data structures
• data dictionaries user interface files, data
• system build files Installation / configuration files
 Structures in software
development process
• There are two structures that SCM is concerned
with
• Problem solving structure
- The system concept evolves through the lifecycle by
successive refinement and elaboration
• Product system structure
- The system is composed of subsystem components, which
are themselves composed of subsystem components
 Configuration Items and
Versions
• A configuration item is a work product (documents, code unit
test etc.) explicitly based under configuration control
• Each time a configuration item is revised and replaced under
configuration control, a new version is created.
• Branch versions are also called Variants
• A configuration is a collection of configuration item versions
that are put together( to form a module, a subsystem a
product, etc..)
 Versions of configuration Items
• Version
- Defined state of an object at a particular time(snap shot)
- Replace a previous version when that object has been further
developed
• variant - One of several versions of an item that exist at the same time
- Item needs to meet similar but different requirements at the same
time(different hardware platforms
Baselining
 Baselining
 A base line is an approved snapshot of the system
at appropriate points in the development life cycle.
 A baseline could be
- Specification
- Product that has been formally reviewed
and agreed upon
 A partial system
 The Value of Baselining
• Change is a fact of line in software development
– Customers want to modify requirements
– Developers want to modify the technical approach
– Management wants to modify the project approach
• Why all of this modification?
– As time passes all parties know more
• about what they need
• which approach would be best
• how to get it done and still make money
– The additional knowledge becomes the driving force behind most changes
• Most change requests are justified!!!
 Baselining
• The fundamental success of any development effort is
dependent on well-defined reference points….against which
to specify requirements, formulate a design, and specify
changes to these requirements and the resultant designs.
• The term baseline is normally used to denote such a
reference point
• A baseline is an approved snapshot of the system at a
given point in its evolution
•
 Baselining-2
• A baseline establishes a formal base for defining
subsequent change
• Without this line or reference point the notion of change is meaningless
• The items in the baseline form the basis for the work in the
next phase of the software development cycle
• The items of the next baseline are measured and verified
against previous baselines before they become baselines
themselves
 Additional Baselines
• The project leader may choose to defines or
create additional baselines on his project to
create points of visibility or stability during
development
• This may be particularly appropriate if an
incremental development approach is adopted or
if the customer demand it
 Summary
• Baselines are created to establish visibility and
stability within a project from which to move
forward.
– The high level design baseline for instance is a definition of the
system architecture from which detailed designs can be
produced.
• A change to baseline is made with a change
request because it is likely to involve new
agreements/contracts with other affected groups
– It may also have an effect on work that has already been
completed in working from the original baseline.
Configuration Change Control
 Configuration Change Control
• Establishing a change control process that
specifies :
- Who can initiate the change request
- The individuals, group, or groups who are responsible
for evaluating, accepting and tracking the change
proposals for the various baseline products
- The “change impact” analysis expected for each
requested change
- How the change history should be kept
 Need for Change Control

• In the ideal world, once a configuration item was

fully approved there would be no need to change
• In the real world new versions of a configuration
item are needed for a variety of reasons
– The requirements for the system change
– The boundaries between items in the design hierarchy
changes
• The precise interface between items may need to be renegotiated as
software is designed and written
 The Need for Change Control-2

• The specification of an item is incomplete or wrongly

interpreted
• An error is found that was not detected during the configuration
items review
• The software environment changes in a way that necessitates
change
• In each case, new version of a configuration item is needed
which supersedes the earlier version
• Replacing one version of a configuration item with a better one
is the objective of all change
 Without Change Control
• Without change control a software engineer could make an important
change to a configuration item or its interfaces without a lot of extra
work and red tape
• But no record would be kept for :
– What the change was and why the change was requested
– Who wanted the change made
– Who approved the change
– Who made the change
– Who verified the change
 Without Change Control- 2

• And it would be hard to fine out

“why doesn’t my software link this morning it linked last night
“why does this regression test fail now? It worked yesterday !”
Why does the product behave this way now? It didn’t before!”
Why are we running out of memory now? We did not have that
problem yesterday
 Change Control
• All changes made to the configuration
management baselines or baseline software
configuration items should be done according to
a documented change control process
• The change control process should specify
Who can initiate
Change Management Process
C h a n g e r e q u e s t d o c u m e n t e d

C h a n g e r e q u e s t e v a l u a t e d

C h a n g e r e q u e s t r e v i e w e d f o r a p p r o

P e n d i n g C C B A p p r o v e d R e j e c t e d

C h a n g e o r d e r p r e p a r e d

C o n f i g u r a t i o n i t e m s , t a s k s , Q C r e q u i r e

C o n f i g u r a t i o n i t e m s c h e c k e d o u t

C h a n g e m a d e ; Q C a c t i v i t i e s c a r r i e d

c o n f i g u r a t i o n a u d i t c a r r i e d o u t

C h a n g e d i t e m s c h e c k e d i n

N e w p r o d u c t r e l e a s e m a d e
 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
Configuration Management
Status Accounting
Status Accounting

An ounce of derivation is worth a

pound of analysis
- Wayne Babich
 Status Accounting
• Maintaining a continuos record of the status and
history of all baselined items and proposed
changes to them.
• Reports on the traceability of changes to the
baseline throughout the software life cycle.
• Answers the questions
- What changes have been made to the system?
- What changes remain to be implemented?
 Status Accounting
• The mechanism that records how a system
evolves and relates to the baseline and any
written agreements at any point in time
• The purpose of software configuration status
accounting is to maintain a continuous record
(changes and actions) of all baselined items.
 Configuration Management
Reports
• CM reports should be generated on a periodic basis and
distributed to all appropriate groups and individuals.
• The configuration management status reports may
include:
– SCCB meeting minutes
– Change request summary and status
– Trouble report summary and status
– Summary of changes made to the software baselines and
their frequency
– Revision history of all configuration items
– Results of software baselines audits
 Status Accounting Uses
• Configuration Management Status Accounting provides
visibility into the system evolution by recording and
reporting the status of all configuration items and the status
of all requests for change
• Questions that Configuration Management Status
Accounting should be able to answer include:
– What is the status of an item ?
– A programmer may want to know whether a specification
has been fully approved
– A programmer may want to know whether a subsystem has
been tested so that the programmer can test his modules
which interface with that subsystem
 Status Accounting Uses-2
– A project leader will wish to track the progress of a
project as items are developed, reviewed , tested and
integrated
• Has change request been approved for rejected by the
SCCB?
– The originator of a change request will want to know if
the SCCB has approved or rejected the request
• Which version of an item implements an approved
change request?
– Once a requested enhancement of a library routine is
implemented, the originator and other developers will
want to know which version of the routine contains the
enhancement
 Summary
• Configuration management status accounting is the means by which key
project or system information can be communicated to everyone
• Project members can easily determine which configuration item should be
used,whether it is subject to a change request, and what a build consists of.
• Project Leaders can easily determine:
– What Cls have passed review,
– Which changes have been completed,
– Which changes are still in progress,
– How many changes have been accepted,
– Which modules are the most volatile ,
– What a build consists of
– What has been delayed to the next release.
Configuration Audits
 Audit Objectives
• Answer the questions:
– Does the system satisfy the requirements?
– Does the documentation represent the system as
built?
– Are all changes incorporated in this version?
– Are only approved changes incorporated in this
version?
• How can one ensure the product’s integrity?
 Product Integrity
• A software product that has product integrity is one that:
– Fulfills customer needs
– Can be easily and completely traced through its lifecycle
– Meets specified performance criteria
– Meets cost expectations
– Meets delivery expectations
• If the software lifecycle is difficult or impossible to trace
– Either the software must be forever frozen
– Each change that is applied to evolve it is high risk with a small
probability of a good return on investment
 Consistency
• In order to achieve product integrity, consistency must be maintained across
the software life-cycle work products including:
– Software plans
– Process descriptions
– System requirements allocated to software
– Software requirements
– Software design
– Code
– Test plans
– Test Specifications
– Test Procedures
 Consistency-2
• Minimal requirements to maintain consistency include:
– Changes to the software life-cycle work products, plans,
process descriptions and activities are proposed analyzed,
and incorporated as appropriate
– The impact of any change request is made before the
change is accepted
– Changes to the system requirements allocated to software
are changed before subsequent software activities and
work products are changed
• Changes to all affected software products,plans,process
descriptions ,and activities are made before the change
request implementation is considered complete
 Configuration Audits
• Changes are negotiated with and communicated to all affected groups
• Changes are tracked to completion
• A software configuration audit should periodically be performed to ensure
that the SCM practices and procedures are rigorously followed
• General ground rules for SCM audits:
– A documented project SCM plan is used as the basis for all SCM audits
– There is adequate preparation for the audit
– The integrity of the software baselines is assessed
 Configuration Audits-2
-The structure and facilities of the configuration management library
system are reviewed
• The completeness and correctness of the software baseline library
contents are verified
• The accuracy if the implementation of the changes to the baselines is
verified
• A successful software configuration audit should be performed before
every major baseline change
• Auditing also entails ensuring that changes made to an existing
baseline, are implemented as intended
 Configuration Audits-3
• Software configuration auditing is continuous,with
increased frequency and depth throughout the
development lifecycle
• SCM audits are highly efforts requiring software
expertise and knowledge at a level equal to or in excess
of that possessed by the development team
PCA/FCA
 Summary: CM functions
What is System The system Consists of the
Configuration Identification following baseline documents and
products..

How are changes control The steps to process changes are ...
to the Configuration
Controlled?

What changes have The system configuration and related

been made to the Status Changes At this line are the combination
system? accounting Of the following baseline changes, pending
Changes...

Does the system The system as currently built differs from

satisfy the Auditing the baseline approved changes as
requirements ? follows….
 Barriers to SCM
• Schedule pressure
– fixes being incorporated as the product is going out the
door

• Lack of automated support

• Individual’s belief that they don’t need CM

 SCM Tools
High End • Platinum’s Harvest
• Pure Atria’s Clear Case
• Countinuus’ Continuus
• SVN
• Intersolv’s PVCS
• MKS’s Source Integrity

• Microsoft’s Visual source

safe
• Perforce Software’s Perforce

Low End
 Bad Excuses
• We apply CM only to source code
• CM is not applicable because using the latest iterative, concurrent, rapid, spiral,
evolutionary life cycle model
• CM hinders persons with initiative from making a quick correction
• CM hinders creativity
• We do not have a change request form because the customer doesn’t want it
• Our CASE tools will automatically do CM
• CM responsibility belongs to our customer
• CM is a clerical task that does not require much skill
• Design documents are not in CM because we want the flexibility to change design easily
• We don’t track change history in data dictionary because our CASE tool has no provision
to do it.
 Assignment-Self Study
1. Understand the following terms with respect to
Configuration Management, how it is performed in the
SCM Tool you use in your project
Basic Setup :-Repository (repo),Server/Client, Working Set/Workin Copy,.
Trunk/Main, workspace

Basic Actions: Add/Revision, Head,Check out/Check in,Checkin Message

Changelog/History/Update/Sync , Revert
Advanced Actions :
– Branch: Diff/Change/Delta
– Merge (or patch): Conflict:
– Resolve:.
– Locking:.
– Breaking the lock: Check out for edit:

2. Study the SCM Plan Content of your project .