SlideShare a Scribd company logo
Software Configuration Management
(SCM)
Topics :
Necessity Of SCM
Baseline
SCM Process
SCI
Version Control
Change Control
Configuration Audit
Status Reporting
SCCS
What is SCM ?
 When you build a computer system, changes happen,
And because it happens, you need to manage it
effectively.
 Deliverables of large s/w project consist of number of
objects, e. g. source code, design document, SRS
document, test document, user manual etc.
These objects are referred & monitored by number of
s/w engs. throughout the lifecycle of the system
 The state of these objects at any point of time is
called ‘configuration’ of s/w product.
SCM ….. (Continued)
 Software Configuration Management is also called as a
‘Change Management’.
 It is an umbrella activity that is applied throughout the s/w
process.
 Changes are dynamic, they can occur at any time to the
system & therefore SCM activities are developed to :
– Identify the change
– Control the change
– Ensure that the change is properly implemented
– Report changes to others who may have an interest
SCM ….. (Continued)
 It is a set of activities that are designed to
manage changes by
– Identifying work products that are likely to change.
– Establishing relationship between them.
– Defining mechanism for managing different.
version of these work products.
– Controlling the change imposed.
– Auditing & Reporting on changes made.
SCM ….. (Continued)
 SCM is different than s/w support
– s/w support is a set of s/w engineering activities
that occur after s/w has been delivered to the
customer.
– SCM is a set of tracking & control activities that
begin when a s/w engineering project begins &
terminates only when the s/w is taken out of
operation.
SCM ….. (Continued)
 SCM is viewed as a SQA activity that is applied
throughout the s/w process.
 The output of the s/w process is information that may
be divided into 3 broad categories :
1. Computer Programs
2. Work products that describe the computer programs
( Documents)
3. Data ( contained within the program or external to it)
– All these items collectively called as s/w
configuration.
Elements of Configuration Management
System
1. Component Elements
 A set of tools coupled within a file management
system (e.g. database) that enable access to &
management of each s/w configuration item.
2. Process Elements
 A collection of procedures & task that define an
effective approach to change management.
Elements of Configuration Management
System ….. (Continued)
3. Construction Elements
 A set of tools that automate the construction of
the s/w by ensuring that the proper set of
validated components ( i.e. correct version) has
been assembled.
3. Human Elements
 To implement effective SCM, the s/w team uses
a set of tools & process features.
Necessity Of SCM
 The most important reason for configuration management is to
control the different deliverable objects. If SCM is not used then
the following problem may occur:
1. Inconsistency problem when objects are replicated.
– Consider a scenario where all the s/w engineers are involved in coding
phase. They have their own local copy of the source code.
– If any engineer is making modifications to his local copy, he is expected
to intimate the changes to other engineers so that such modification is
reflected in his teammates copies also (to maintain consistency)
– But many times an engineer makes modifications only to his copy & may
forget to intimate the changes to his teammates.
– Finally when the product is integrated, it does not work.
– Therefore, when several team members work on developing an object, it
is necessary for them to work on a single copy of the object, otherwise
inconsistency may arise.
Necessity Of SCM …(Continued)
2. Problems associated with concurrent access.
– If engineers are working on a single copy of the object at same
time, then inconsistency can still occur.
– For eg – if the engineers are concurrently accessing any object
( modifying the code), then while saving the work, one
engineer’s work can be overwritten by other engineer’s work.
( Leading to inconsistency)
2. Providing a stable development environment.
– When a project is under construction, the team members need a stable
environment for progress.
– For eg – suppose you want to integrate module A with B & C; you can’t
make progress if the developer of module C keeps changing C; this can
be frustrating if a change to module C forces you to recompile A.
– This problem can be avoided by using configuration management,
where the manager freezes the object to form a baseline.
Necessity Of SCM …(Continued)
– When any user needs any of the object to be changed,
he is provided with a copy of a baseline item.
– The user then makes changes to his private copy. Only
if the user is through with all modifications in his private
copy, change is updated to form the new baseline.
4. System accounting & maintaining status
information
– System accounting keeps track of who made a
particular change & when the change was made.
Baseline
 A baseline is a SCM concept that helps us to
control change without seriously impeding
justifiable change.
 The IEEE defines a baseline as :
“A specification or product that has been formally
reviewed & agreed upon, that thereafter serves as
the basis for further development, and that can be
changed only through formal change control
procedures.”
Baseline …(Continued)
 Before a software configuration item (SCI)
becomes a baseline, changes may be made
quickly & informally.
 However, once the baseline is established,
changes can be made, but a specific, formal
procedure must be applied to evaluate &
verify each change.
Baseline …(Continued)
 In the context of S.E. – a baseline is a milestone in
the development of the s/w.
 A baseline is marked by the delivery of one or more
SCI that have been approved as a consequence of
formal technical review.
 For e.g. – the elements of the design model have
been documented & reviewed. Errors are found &
corrected. Once all parts of the model have been
reviewed, corrected & then approved, the design
model becomes a baseline.
Baseline …(Continued)
Baseline …(Continued)
 Explanation for above fig. –
– S.E. task produces one or more SCI’s.
– After SCI’s are reviewed & approved they are
placed in project database.
– When member of s/w team wants to make
modification to a baselined SCI, it should be copied
from the project database into the engineer’s private
workspace.
– These extracted SCI’s can be modified only if SCM
controls are followed.
S/w Configuration Item (SCI)
 SCI is information that is created as a part of the s/w
engineering process.
 It can be a document, a entire suit of test cases, a
named program component like a C++ function or a
java applet.
 Not only the SCI’s which are derived from different
work products are placed in configuration control, but
also some of the imp. tools like compilers, linkers,
browsers, editors, other automated tools are also a
part of configuration control.
SCI …(Continued)
 Why these tools are placed as a part of
Configuration control?
– Because, these tools are used to produce documentation,
source code & data, they my be available when changes to
the s/w configuration are to be made.
– It is possible that a new version of tool (e.g., a compiler)
might produce different results than the original version
– For this reason, tools, like the s/w that they help to produce,
can be baselined as a part of a comprehensive
configuration management process.
SCI …(Continued)
 In reality, all SCI’s are organized to form
configuration objects & is placed in project
database with a single name.
 A configuration object has a name, attributes & is
connected to other objects by a relationship.
SCI …(Continued)
 The configuration objects, Design
Specification, DataModel,
ComponentN, SourceCode &
TestSpecification are each
defined seperately.
 Each of the object is related to
others as shown by arrows.
 A curved arrow indicates a
compositional relation. i.e.
DataModel & ComponentN are
part of DesignSpecification.
 A double headed straight arrow
indicates an interrelationship.
 If a change were made to the
source code object, the
interrelationship enables a s/w
engineer to determine what other
objects might be affected?
SCM Process
 The SCM Process Defines the series of
tasks that have 4 primary objectives :
1. To identify all items that collectively define the
s/w configuration
2. To manage changes to one or more these items
3. To facilitate the construction of different versions
of an application
4. To ensure that s/w quality is maintained as the
configuration evolves over time.
SCM Process …(Continued)
 To ensure that s/w quality is maintained as the changes are
accepted over time, SCM tasks can be viewed as concentric layers.
 5 SCM Tasks:
1. Identification
2. Change Control
3. Version Control
4. Configuration
Auditing
5. Reporting
SCI’s
Identification
Change Control
Version Control
Configuration Auditing
Reporting
SCM Process …(Continued)
 The software configuration items (SCI’s) flow outward
through these layers throughout their lifetime.
 So, they become a part of s/w configuration of one or
more versions of an application or system.
 When SCI moves through different layers, the actions
specified for each & every layer need not be applied
(not a must) to them.
 E.g.
– When a new SCI is created, it must be identified. However, if no
changes are requested for the SCI, the change control layer does not
apply.
– Each & every SCI created is also assigned to a specific version of
the s/w
– The record of all these SCI’s (i.e. it’s name, creation date, version
etc.) is maintained for configuration auditing purpose.
SCM Process …(Continued)
 Identification of object in s/w configuration
– To control & manage s/w configuration items, each should
be separately named & then organized using an object
oriented approach.
– 2 types of objects can be identified:
1. Basic Objects
2. Aggregate Objects
– Basic Object – is a unit of information that has been
created by a s/w engineer during analysis, design, code or
test.
e.g. It might be a section of a requirement specification, part of
design model, source code for a component etc.
SCM Process …(Continued)
– Aggregate Object – is a collection of basic objects & other
aggregate objects
– Each object has a set of distinct features that identify it
uniquely (i.e. name, a description, a list of resources & a
realization)
– An object name is a character string that identifies the
object uniquely.
– The object description is a list of data items that identify the
SCI type represented by the object, change or version
information.
– For e.g. – by using the simple notation
Class diagram <part –of> analysis model;
Analysis Model <part-of> requirement specification;
We can create hierarchy of SCI.
Change Control
 For a large s/w engineering projects, uncontrolled changes
rapidly leads to chaos.
 Change control includes both human procedures & automated
tools.
 The change control process is illustrated below:
Change Control …(Continued)
Change Control …(Continued)
Change Control …(Continued)
 Explanation for change control process :
– A request for a change is submitted & evaluated to assess the
merits, side effects, overall impact on other configuration
objects, cost incurred on these changes etc.
– The result of such evaluation is presented as a Change
Report.
– This report is verified by CCA (change control authority – a
person or a group) who makes the final decision for approval
or disapproval of change report.
– For each approved change, ECO (engineering change order)
is generated. The ECO describes
 the change to be made
 The constraints that must be respected
 & the criteria for review & audit.
Change Control …(Continued)
– The object (s) to be changed can be “checked
out” of the project database, change is made, &
appropriate SQA activities are applied.
– The object (s) is then “checked in” to the
database & then appropriate version control
mechanisms are used to create the next version
of the s/w.
– These version control mechanisms, implement 2
important elements of change management:
1. Access Control
2. Synchronization Control
Change Control …(Continued)
– Once the object has undergone formal technical
review & has been approved, a baseline can be
created.
– Once a SCI becomes a baseline, ‘Project Level
Change Control’ is implemented.
– Now, to make a change, the developer must gain
approval from the project manager or from CCA.
– Once approved by CCA, these changes can be
promoted for inclusion in next release.
– Then built the new version if needed & then
distribute the new version.
Version Control
 When item is baselined, it become frozen. The term frozen
means that the item can only be changed by creating a new
version.
 Version control combines procedures & tools to manage
different versions of configuration objects that are created
during the s/w process
 A version control system is integrated with following
capabilities:
1. A project database (repository) that stores all relevant
configuration objects
2. A version management capability that stores all versions of
configuration objects
3. A make facility that enables the engineers to collect all the
configuration objects & construct the specific version of a
software
Version Control …(Continued)
 A number of version control systems establish a
change set –
– A change set is a collection of all changes that are required
to create a specific version of a s/w.
– It captures all changes to all files in the configuration along
with the reason for changes & details of who made the
changes & when.
 Hence, for any application a number of named
change sets can be identified. These named change
sets enable the engineers to construct the version of
the s/w by specifying change to baseline
configuration.
Version Control …(Continued)
 One representation of the different versions of a system
is the evolution graph which is shown in the following
figure.
 Here, each node is
a complete version
of the s/w.
 Each version is the
collection of SCI’s
Configuration Audit
 To ensure that the changes has been properly
implemented, 2 methods are used :
1. Formal Technical Reviews
2. Software configuration audit
1. Formal Technical Reviews
 Focuses on the technical correctness of the configuration
object that has been modified.
 The reviewers assess the SCI to determine consistency with
other SCI’s or potential side effects.
 The formal technical review must be conducted for all but the
most trivial changes.
Configuration Audit …(Continued)
2. Software Configuration Audit
 SCA assess configuration object for characteristics that are
not considered during Formal Technical Reviews.
 The audit answers the following questions :
1. Has the change specified in the ECO been made? Have any
additional modifications been incorporated?
2. Has a formal technical review been conducted to assess
technical correctness?
3. Has the s/w process been followed & have s/w engineering
standards been properly applied?
4. Has the changes been highlighted in SCI? Have the change
date & change author been specified?
5. Have SCM process been followed?
6. Have all related SCI’s been properly updated?
Configuration Audit …(Continued)
 In some cases, the audit questions are asked as
part of formal technical review.
 When SCM is a formal activity, the SCM audit is
conducted separately by the quality assurance
group.
 Such formal configuration audits also ensure
that the correct SCI’s have been incorporated
into a specific build & all documents are up-to-
date & consistent with the version that has been
built.
Status Reporting
 Also called as ‘status accounting’, is a SCM task
that answers the following questions :
1. What happened?
2. Who did it?
3. When did it happen?
4. What else will be affected?
 The Status Reporting entry is made in the following
conditions
– SCI is assigned a new or updated identification
– a change is approved by CCA
– Whenever the configuration audit is conducted, the results
are reported.
Status Reporting …(Continued)
 Output from status reporting may be placed
in an on-line database or a website, so that
s/w developers or maintainers can access
change information.
Source Code Control System (SCCS)
 SCCS is a system for controlling changes to files of
text (typically, the source code& documentation of
s/w system)
 It is an integral part of a s/w development &
maintenance system known as ‘Programmers
Workbench’
 It was the 1st
Source code revision control system.
 Originally developed at Bell Labs in 1972 for IBM
system.
 It was later rewritten for UNIX
 It is used to store versions in compact manner by
minimizing the amount of disc space

More Related Content

PPTX
Phased life cycle model
PPTX
software cost factor
PPTX
Software Configuration Management
PPT
Software Configuration Management
PPTX
Software Configuration Management (SCM)
PPTX
Language and Processors for Requirements Specification
PPTX
Software Development Life Cycle (SDLC )
PPTX
COCOMO (Software Engineering)
Phased life cycle model
software cost factor
Software Configuration Management
Software Configuration Management
Software Configuration Management (SCM)
Language and Processors for Requirements Specification
Software Development Life Cycle (SDLC )
COCOMO (Software Engineering)

What's hot (20)

PPTX
Software Configuration Management
PPTX
Project scheduling and tracking
PPTX
Software configuration management
PPTX
Design techniques
PPTX
Software Cost Estimation Techniques
PPTX
Software maintenance
PDF
Validation & verification software engineering
PPTX
Chapter 1 2 - some size factors
PPTX
Algorithmic Software Cost Modeling
PPTX
COCOMO model
PPTX
software configuration management ppt
PDF
structure chart.pdf
PPTX
Software Process Models
PPT
Software design
PPTX
Software requirements specification
PPT
Configuration Management
PPTX
formal verification
PPT
Software Testing Strategies
PPT
Architectural Design in Software Engineering SE10
PPTX
Walkthroughs
Software Configuration Management
Project scheduling and tracking
Software configuration management
Design techniques
Software Cost Estimation Techniques
Software maintenance
Validation & verification software engineering
Chapter 1 2 - some size factors
Algorithmic Software Cost Modeling
COCOMO model
software configuration management ppt
structure chart.pdf
Software Process Models
Software design
Software requirements specification
Configuration Management
formal verification
Software Testing Strategies
Architectural Design in Software Engineering SE10
Walkthroughs
Ad

Viewers also liked (9)

PPT
software configuratiom management role n resposnbilities
PPTX
Best Practices to Implement an Effective Change Control Program Company Wide
PPTX
Version control, issue tracking and communication
PPTX
Software configuration management
PPT
Change control
PPT
Software design methodologies
PPTX
Engineering Change Management - Overview and Best Practices
PPT
Design concepts and principles
software configuratiom management role n resposnbilities
Best Practices to Implement an Effective Change Control Program Company Wide
Version control, issue tracking and communication
Software configuration management
Change control
Software design methodologies
Engineering Change Management - Overview and Best Practices
Design concepts and principles
Ad

Similar to 5. scm (20)

PPT
Software Configuration Management introduction
PPT
lecture14.ppt
PPT
Software configuration management of students
PDF
Unit 6 Software Configuration Management
PPT
Software Engineering (Software Configuration Management)
PPT
Fa10 mcs-005
PPTX
SE-Lecture-8.pptx
PPT
Software Configuration Management.ppt
PPSX
Software Project Planning IV
PPT
PPT
PPTX
Software Configuration Management (SCM)
PPT
Software maintenance and configuration management, software engineering
PPTX
Software Configuration Management.pptx
PDF
software configuration management
PPT
Configuration Management
PPTX
Software Configuration Management PPT for Software Engg
PPT
Software configuration management
PPT
Software configuration management, Web engineering
Software Configuration Management introduction
lecture14.ppt
Software configuration management of students
Unit 6 Software Configuration Management
Software Engineering (Software Configuration Management)
Fa10 mcs-005
SE-Lecture-8.pptx
Software Configuration Management.ppt
Software Project Planning IV
Software Configuration Management (SCM)
Software maintenance and configuration management, software engineering
Software Configuration Management.pptx
software configuration management
Configuration Management
Software Configuration Management PPT for Software Engg
Software configuration management
Software configuration management, Web engineering

Recently uploaded (20)

PPTX
Understanding_Digital_Forensics_Presentation.pptx
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PDF
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
PDF
Bridging biosciences and deep learning for revolutionary discoveries: a compr...
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PDF
Unlocking AI with Model Context Protocol (MCP)
PDF
cuic standard and advanced reporting.pdf
PPTX
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
PPTX
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
PDF
NewMind AI Weekly Chronicles - August'25 Week I
PPTX
Cloud computing and distributed systems.
PDF
Review of recent advances in non-invasive hemoglobin estimation
DOCX
The AUB Centre for AI in Media Proposal.docx
PDF
Agricultural_Statistics_at_a_Glance_2022_0.pdf
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
Machine learning based COVID-19 study performance prediction
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
Understanding_Digital_Forensics_Presentation.pptx
Mobile App Security Testing_ A Comprehensive Guide.pdf
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
20250228 LYD VKU AI Blended-Learning.pptx
Reach Out and Touch Someone: Haptics and Empathic Computing
Bridging biosciences and deep learning for revolutionary discoveries: a compr...
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Diabetes mellitus diagnosis method based random forest with bat algorithm
Unlocking AI with Model Context Protocol (MCP)
cuic standard and advanced reporting.pdf
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
NewMind AI Weekly Chronicles - August'25 Week I
Cloud computing and distributed systems.
Review of recent advances in non-invasive hemoglobin estimation
The AUB Centre for AI in Media Proposal.docx
Agricultural_Statistics_at_a_Glance_2022_0.pdf
Spectral efficient network and resource selection model in 5G networks
Machine learning based COVID-19 study performance prediction
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx

5. scm

  • 1. Software Configuration Management (SCM) Topics : Necessity Of SCM Baseline SCM Process SCI Version Control Change Control Configuration Audit Status Reporting SCCS
  • 2. What is SCM ?  When you build a computer system, changes happen, And because it happens, you need to manage it effectively.  Deliverables of large s/w project consist of number of objects, e. g. source code, design document, SRS document, test document, user manual etc. These objects are referred & monitored by number of s/w engs. throughout the lifecycle of the system  The state of these objects at any point of time is called ‘configuration’ of s/w product.
  • 3. SCM ….. (Continued)  Software Configuration Management is also called as a ‘Change Management’.  It is an umbrella activity that is applied throughout the s/w process.  Changes are dynamic, they can occur at any time to the system & therefore SCM activities are developed to : – Identify the change – Control the change – Ensure that the change is properly implemented – Report changes to others who may have an interest
  • 4. SCM ….. (Continued)  It is a set of activities that are designed to manage changes by – Identifying work products that are likely to change. – Establishing relationship between them. – Defining mechanism for managing different. version of these work products. – Controlling the change imposed. – Auditing & Reporting on changes made.
  • 5. SCM ….. (Continued)  SCM is different than s/w support – s/w support is a set of s/w engineering activities that occur after s/w has been delivered to the customer. – SCM is a set of tracking & control activities that begin when a s/w engineering project begins & terminates only when the s/w is taken out of operation.
  • 6. SCM ….. (Continued)  SCM is viewed as a SQA activity that is applied throughout the s/w process.  The output of the s/w process is information that may be divided into 3 broad categories : 1. Computer Programs 2. Work products that describe the computer programs ( Documents) 3. Data ( contained within the program or external to it) – All these items collectively called as s/w configuration.
  • 7. Elements of Configuration Management System 1. Component Elements  A set of tools coupled within a file management system (e.g. database) that enable access to & management of each s/w configuration item. 2. Process Elements  A collection of procedures & task that define an effective approach to change management.
  • 8. Elements of Configuration Management System ….. (Continued) 3. Construction Elements  A set of tools that automate the construction of the s/w by ensuring that the proper set of validated components ( i.e. correct version) has been assembled. 3. Human Elements  To implement effective SCM, the s/w team uses a set of tools & process features.
  • 9. Necessity Of SCM  The most important reason for configuration management is to control the different deliverable objects. If SCM is not used then the following problem may occur: 1. Inconsistency problem when objects are replicated. – Consider a scenario where all the s/w engineers are involved in coding phase. They have their own local copy of the source code. – If any engineer is making modifications to his local copy, he is expected to intimate the changes to other engineers so that such modification is reflected in his teammates copies also (to maintain consistency) – But many times an engineer makes modifications only to his copy & may forget to intimate the changes to his teammates. – Finally when the product is integrated, it does not work. – Therefore, when several team members work on developing an object, it is necessary for them to work on a single copy of the object, otherwise inconsistency may arise.
  • 10. Necessity Of SCM …(Continued) 2. Problems associated with concurrent access. – If engineers are working on a single copy of the object at same time, then inconsistency can still occur. – For eg – if the engineers are concurrently accessing any object ( modifying the code), then while saving the work, one engineer’s work can be overwritten by other engineer’s work. ( Leading to inconsistency) 2. Providing a stable development environment. – When a project is under construction, the team members need a stable environment for progress. – For eg – suppose you want to integrate module A with B & C; you can’t make progress if the developer of module C keeps changing C; this can be frustrating if a change to module C forces you to recompile A. – This problem can be avoided by using configuration management, where the manager freezes the object to form a baseline.
  • 11. Necessity Of SCM …(Continued) – When any user needs any of the object to be changed, he is provided with a copy of a baseline item. – The user then makes changes to his private copy. Only if the user is through with all modifications in his private copy, change is updated to form the new baseline. 4. System accounting & maintaining status information – System accounting keeps track of who made a particular change & when the change was made.
  • 12. Baseline  A baseline is a SCM concept that helps us to control change without seriously impeding justifiable change.  The IEEE defines a baseline as : “A specification or product that has been formally reviewed & agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.”
  • 13. Baseline …(Continued)  Before a software configuration item (SCI) becomes a baseline, changes may be made quickly & informally.  However, once the baseline is established, changes can be made, but a specific, formal procedure must be applied to evaluate & verify each change.
  • 14. Baseline …(Continued)  In the context of S.E. – a baseline is a milestone in the development of the s/w.  A baseline is marked by the delivery of one or more SCI that have been approved as a consequence of formal technical review.  For e.g. – the elements of the design model have been documented & reviewed. Errors are found & corrected. Once all parts of the model have been reviewed, corrected & then approved, the design model becomes a baseline.
  • 16. Baseline …(Continued)  Explanation for above fig. – – S.E. task produces one or more SCI’s. – After SCI’s are reviewed & approved they are placed in project database. – When member of s/w team wants to make modification to a baselined SCI, it should be copied from the project database into the engineer’s private workspace. – These extracted SCI’s can be modified only if SCM controls are followed.
  • 17. S/w Configuration Item (SCI)  SCI is information that is created as a part of the s/w engineering process.  It can be a document, a entire suit of test cases, a named program component like a C++ function or a java applet.  Not only the SCI’s which are derived from different work products are placed in configuration control, but also some of the imp. tools like compilers, linkers, browsers, editors, other automated tools are also a part of configuration control.
  • 18. SCI …(Continued)  Why these tools are placed as a part of Configuration control? – Because, these tools are used to produce documentation, source code & data, they my be available when changes to the s/w configuration are to be made. – It is possible that a new version of tool (e.g., a compiler) might produce different results than the original version – For this reason, tools, like the s/w that they help to produce, can be baselined as a part of a comprehensive configuration management process.
  • 19. SCI …(Continued)  In reality, all SCI’s are organized to form configuration objects & is placed in project database with a single name.  A configuration object has a name, attributes & is connected to other objects by a relationship.
  • 20. SCI …(Continued)  The configuration objects, Design Specification, DataModel, ComponentN, SourceCode & TestSpecification are each defined seperately.  Each of the object is related to others as shown by arrows.  A curved arrow indicates a compositional relation. i.e. DataModel & ComponentN are part of DesignSpecification.  A double headed straight arrow indicates an interrelationship.  If a change were made to the source code object, the interrelationship enables a s/w engineer to determine what other objects might be affected?
  • 21. SCM Process  The SCM Process Defines the series of tasks that have 4 primary objectives : 1. To identify all items that collectively define the s/w configuration 2. To manage changes to one or more these items 3. To facilitate the construction of different versions of an application 4. To ensure that s/w quality is maintained as the configuration evolves over time.
  • 22. SCM Process …(Continued)  To ensure that s/w quality is maintained as the changes are accepted over time, SCM tasks can be viewed as concentric layers.  5 SCM Tasks: 1. Identification 2. Change Control 3. Version Control 4. Configuration Auditing 5. Reporting SCI’s Identification Change Control Version Control Configuration Auditing Reporting
  • 23. SCM Process …(Continued)  The software configuration items (SCI’s) flow outward through these layers throughout their lifetime.  So, they become a part of s/w configuration of one or more versions of an application or system.  When SCI moves through different layers, the actions specified for each & every layer need not be applied (not a must) to them.  E.g. – When a new SCI is created, it must be identified. However, if no changes are requested for the SCI, the change control layer does not apply. – Each & every SCI created is also assigned to a specific version of the s/w – The record of all these SCI’s (i.e. it’s name, creation date, version etc.) is maintained for configuration auditing purpose.
  • 24. SCM Process …(Continued)  Identification of object in s/w configuration – To control & manage s/w configuration items, each should be separately named & then organized using an object oriented approach. – 2 types of objects can be identified: 1. Basic Objects 2. Aggregate Objects – Basic Object – is a unit of information that has been created by a s/w engineer during analysis, design, code or test. e.g. It might be a section of a requirement specification, part of design model, source code for a component etc.
  • 25. SCM Process …(Continued) – Aggregate Object – is a collection of basic objects & other aggregate objects – Each object has a set of distinct features that identify it uniquely (i.e. name, a description, a list of resources & a realization) – An object name is a character string that identifies the object uniquely. – The object description is a list of data items that identify the SCI type represented by the object, change or version information. – For e.g. – by using the simple notation Class diagram <part –of> analysis model; Analysis Model <part-of> requirement specification; We can create hierarchy of SCI.
  • 26. Change Control  For a large s/w engineering projects, uncontrolled changes rapidly leads to chaos.  Change control includes both human procedures & automated tools.  The change control process is illustrated below:
  • 29. Change Control …(Continued)  Explanation for change control process : – A request for a change is submitted & evaluated to assess the merits, side effects, overall impact on other configuration objects, cost incurred on these changes etc. – The result of such evaluation is presented as a Change Report. – This report is verified by CCA (change control authority – a person or a group) who makes the final decision for approval or disapproval of change report. – For each approved change, ECO (engineering change order) is generated. The ECO describes  the change to be made  The constraints that must be respected  & the criteria for review & audit.
  • 30. Change Control …(Continued) – The object (s) to be changed can be “checked out” of the project database, change is made, & appropriate SQA activities are applied. – The object (s) is then “checked in” to the database & then appropriate version control mechanisms are used to create the next version of the s/w. – These version control mechanisms, implement 2 important elements of change management: 1. Access Control 2. Synchronization Control
  • 31. Change Control …(Continued) – Once the object has undergone formal technical review & has been approved, a baseline can be created. – Once a SCI becomes a baseline, ‘Project Level Change Control’ is implemented. – Now, to make a change, the developer must gain approval from the project manager or from CCA. – Once approved by CCA, these changes can be promoted for inclusion in next release. – Then built the new version if needed & then distribute the new version.
  • 32. Version Control  When item is baselined, it become frozen. The term frozen means that the item can only be changed by creating a new version.  Version control combines procedures & tools to manage different versions of configuration objects that are created during the s/w process  A version control system is integrated with following capabilities: 1. A project database (repository) that stores all relevant configuration objects 2. A version management capability that stores all versions of configuration objects 3. A make facility that enables the engineers to collect all the configuration objects & construct the specific version of a software
  • 33. Version Control …(Continued)  A number of version control systems establish a change set – – A change set is a collection of all changes that are required to create a specific version of a s/w. – It captures all changes to all files in the configuration along with the reason for changes & details of who made the changes & when.  Hence, for any application a number of named change sets can be identified. These named change sets enable the engineers to construct the version of the s/w by specifying change to baseline configuration.
  • 34. Version Control …(Continued)  One representation of the different versions of a system is the evolution graph which is shown in the following figure.  Here, each node is a complete version of the s/w.  Each version is the collection of SCI’s
  • 35. Configuration Audit  To ensure that the changes has been properly implemented, 2 methods are used : 1. Formal Technical Reviews 2. Software configuration audit 1. Formal Technical Reviews  Focuses on the technical correctness of the configuration object that has been modified.  The reviewers assess the SCI to determine consistency with other SCI’s or potential side effects.  The formal technical review must be conducted for all but the most trivial changes.
  • 36. Configuration Audit …(Continued) 2. Software Configuration Audit  SCA assess configuration object for characteristics that are not considered during Formal Technical Reviews.  The audit answers the following questions : 1. Has the change specified in the ECO been made? Have any additional modifications been incorporated? 2. Has a formal technical review been conducted to assess technical correctness? 3. Has the s/w process been followed & have s/w engineering standards been properly applied? 4. Has the changes been highlighted in SCI? Have the change date & change author been specified? 5. Have SCM process been followed? 6. Have all related SCI’s been properly updated?
  • 37. Configuration Audit …(Continued)  In some cases, the audit questions are asked as part of formal technical review.  When SCM is a formal activity, the SCM audit is conducted separately by the quality assurance group.  Such formal configuration audits also ensure that the correct SCI’s have been incorporated into a specific build & all documents are up-to- date & consistent with the version that has been built.
  • 38. Status Reporting  Also called as ‘status accounting’, is a SCM task that answers the following questions : 1. What happened? 2. Who did it? 3. When did it happen? 4. What else will be affected?  The Status Reporting entry is made in the following conditions – SCI is assigned a new or updated identification – a change is approved by CCA – Whenever the configuration audit is conducted, the results are reported.
  • 39. Status Reporting …(Continued)  Output from status reporting may be placed in an on-line database or a website, so that s/w developers or maintainers can access change information.
  • 40. Source Code Control System (SCCS)  SCCS is a system for controlling changes to files of text (typically, the source code& documentation of s/w system)  It is an integral part of a s/w development & maintenance system known as ‘Programmers Workbench’  It was the 1st Source code revision control system.  Originally developed at Bell Labs in 1972 for IBM system.  It was later rewritten for UNIX  It is used to store versions in compact manner by minimizing the amount of disc space