SOFTWARE QUALITY

ENGINEERING
Course Outline
Course Outline (Cont….)

Course Contents
Lecture 11 Cost of Quality
Lecture 12 Software Quality Metrics
Lecture 13 Introduction of Testing Tool (Guest Lecture)
Lecture 14 Course Recap
 LECTURE # 9

CONFIGURATION AND
CHANGE MANAGEMENT
Today’s Plan
 Basic sources of Change
 Definition of SCM
 SCM Tasks
 Why Change Management?
 SCM Terminology
 Version, Variant, Revision and Branch
 Baseline
 Change Control Process
Change
Definition:
Any deviation from a
previously
approved baseline.
“There is nothing permanent except CHANGE”
Heraclitus (500 B.C)
Opening Scenario – The Problem
 This worked yesterday! What
happened now?
 I can not replicate this bug in
my copy?
 What happened to my fix of
last week?
 Was that bug fixed in this
copy?
The solution
 Needs coordination.
 Software Configuration Management
 Manages evolving software systems
 Controls the costs involved in making changes to a
system
Background
 Changes are inevitable when software is built. A
primary goal of software engineering is to improve
the ease with which changes can be made to software.
 Configuration management is all about change
control. Every software engineer has to be concerned
with how changes made to work products are tracked
and propagated throughout a project.
 To ensure that quality is maintained the change
process must be audited.
Basic sources of Change
 New business or market conditions dictate changes to product
requirements or business rules.
 New customer needs demand modification of data,
functionality, or services.
 Business reorganization causes changes in project priorities or
software engineering team structure.
 Budgetary or scheduling constraints cause system to be
redefined.
 Defects reported from live environment.
Definition of SCM
 Software Configuration Management is a discipline
for controlling the evolution of software systems.
 Software Configuration Management is again an
umbrella activity that is applied throughout the
software process.
 Every one involved in the software engineering
process is involved with SCM to some extent.
 A Change Control Board (CCB) is the governing
body for modifications after implementation.
What CM is not?
 Not just version control.
 Not just for source code management.
 Not only for development phase.
 Selecting and using tools are important, but design
and management of Configuration Management
process are more crucial for project success.
SCM Tasks
 SCM tasks are broadly defined into 5 categories:
 Identifications of objects
 Version Control
 Change Control
 Configuration Auditing
 Status Reporting
SCM Activities
Change can occur at any time, SCM activities are developed to:

 Identify Change

 Control Change
SCM Activities

 Ensure that change is being properly

implemented

 Report changes
SCM Roles
Project Manager

Software Configuration
Control Board

SCM Group

Project Members

Line Manager

SQA Group
Why Change Management?
 Initiated when the project begins and terminates
when the software is discontinued.
 Prevent scope creep.
 Allow the impact of all changes to be understood
and managed.
 Allow each change to be accepted, rejected, or
deferred by the appropriate authority:
 Management
 Customer
 etc
Follow-up Actions
 If accepted
 Plan incorporation into the system
 Create new baselines
 Modify the schedule and allocate resources
 If rejected
 Communicate and document the decision
 If deferred
 Perform further analysis
 Consider further alternatives
 Hold until a specified time
Factors in change analysis
 The consequences of not making the change.
 The benefits of the change.
 The number of users affected by the change.
 The costs of making the change.
 The product release cycle.
Change Request Form - Template
Version Control
 A new version is defined when major changes have been
made to one or more objects.
 Combines procedures and tools to manage the different
versions of configuration objects created during the
software process.
SCM Terminology
 Configuration
 Configuration Item (CI)
 Version, Variant, and Revision
 Baseline
 Workspace
Configuration
 An arrangement of functional CIs according to their
nature, version and other characteristics.
 Sometimes, configuration needs to record
environment details, e.g. compiler version, library
version, hardware platform, etc.
 Computer programs
 Source code, Executable code
 Documents that describe the computer programs
 For technical staff, For users
 Data
 Within the program and external to it
Software Configuration Item
 A document or an artifact
that is explicitly placed
under configuration control
and that can be regarded as a
basic unit for modification.
 Examples:
 Requirement documents
 Design document
 Source code
 Test plan
 User manual
Version, Variant, Revision and
Branch
Version
 An instance of a system which is
functionally distinct in some way
from other system instances.
 A configuration item at one point
in its development, includes
revision and variant.
Revision
A revision is a new version that
does include corrections,
clarifications etc, but no additional
components, functionality.
Variant
Functionally equivalent versions, but
designed for different settings:
 e.g. Natural language "versions" (English,
French, ...)
 Versions for different operating systems
Branch
A sequence of versions in the
time
line.
Baseline
 Definition
The originally approved plan plus or minus
approved changes.
 Baselines are used to compare the actual
performance and forecasts of the project with the
original plan.
Baseline (cont…)
 A work product becomes a baseline only after it is
reviewed and approved.
 A baseline is a milestone in software development
that is marked by the delivery of one or more
configuration items.
 Once a baseline is established each change request
must be evaluated and verified by a formal
procedure before it is processed.
Workspace
 An isolated environment where a developer can
work (edit, change, compile, test) without
interfering other developers.
 Examples:
 Local directory under version control
 Private workspace on the server
 Common operations:
 Check out: get a version into workspace
 Check in: commit changes to the repository
Change Control Process
 Submission of Change Request (CR)
 Technical and business evaluation and impact analysis
 Approval by Change Control Board (CCB)
 Engineering Change Order (ECO) is generated stating
 changes to be made
 criteria for reviewing the changed Configuration Item
 CI’s checked out
 Changes made and reviewed
 CI’s checked in
Change Control Process
Class ahead

Software Testing Automation