Software Quality Assurance

Lecture # 6

Software Configuration
Management-II
AYESHA RAANA

Lecturer

COMPUTER SCIENCE DEPARTMENT

GCWU SIALKOT

Email:: ayesha.raana@gcwus.edu.pk

Office #:: CS/IT FACULTY ROOM, IT BLOCK

 Presentation Outline

- Version Control

- Change Control

- Configuration Audit

- Status Reporting
 Versions/variants/releases/revision
Version An instance of a system which is functionally distinct in
some way from other system instances.

Variant An instance of a system which is functionally identical but

non-functionally distinct from other instances of a system. A variant
is a new version that does not replace the old version

Release An instance of a system which is distributed to users

outside of the development team.

Revision A revision is a new version that does includes corrections,

clarifications etc, but no additional components, functionality.
 Version Control

To illustrate the concept of variant, consider a version of a simple

program that is composed of entities 1,2,3,4 and 5.

 Entity 4 is used only when the software is implemented using color

displays.

 Entity 5 is implemented when monochrome displays are available.

 Therefore two variants of the version can be defined:

 entities 1,2,3 and 4

 entities 1,2,3 and 5

 To construct the appropriate variant of a given version of the

program, each entity can be assigned an “attribute-tuple” – “a list
of features that will define whether a particular variant of a software
version is to be constructed”
 Version Control

 Version Control combines procedures and tools to manage different

versions of configuration objects that are created during the software
process

 Revision control, also known as version control, source

control is the management of changes to documents, programs,
and other information stored as computer files

 Version control can be managed in the following ways:

 Evolution graph to represent different versions

 Uses an object pool representing components, variants and

versions, and their relationship

 RCS (Revision Control System)

 Version Control
 Revision / Version control systems either use a centralized model
or a distributed model

 Traditional revision control systems use a centralized model

where all the revision control functions take place on a shared server.

 Centralized model includes a central code repository where every

client synchronizes
Version and Change Tracking-- Repository Systems
Version and Change Tracking-- Repository Systems
Conflicts

 If two developers try to change the same file at the same time,
without some method of managing access the developers may end
up overwriting each other's work.

 Centralized revision control systems solve this problem in one of

two different "source management models":

 file locking and

 version merging.
 Version Control

File locking (Pessimistic Approach)

 The simplest method of preventing "concurrent access" problems

involves locking files so that only one developer at a time has write
access to the central "repository" copies of those files.

 Once one developer "checks out" a file, others can read that file,
but no one else may change that file until that developer "checks in"
the updated version (or cancels the checkout).

 File locking has both merits and drawbacks.

 It can provide some protection against difficult merge conflicts when a

user is making radical changes to many sections of a large file (or
group of files).

 However, if the files are left exclusively locked for too long, other
developers may be tempted to bypass the revision control software
and change the files locally, leading to more serious problems.
 Version Control

Version Merging (Optimistic Approach)

 Most version control systems, such as CVS, allow multiple

developers to edit the same file at the same time.

 The first developer to "check in" changes to the central repository

always succeeds.

 The system provides facilities to merge changes into the central

repository, thus preserving the changes from the first developer
when the other developers check in.

 The second developer checking in code will need to take care with
the merge, to make sure that the changes are compatible and that
the merge operation does not introduce its own logic errors within
the program.
 Version Control
 Distributed revision control systems takes a peer-to-peer
approach, as opposed to the client-server approach of centralized
systems.

 Rather than a single, central repository on which clients

synchronize, each peer's working copy of the codebase is a bona-fide
repository.

 Distributed revision control conducts synchronization by exchanging

patches (change-sets) from peer to peer. This results in some
important differences from a centralized system:

 No reference copy of the codebase exists by default; only working

copies.

 Common operations (such as commits, viewing history, and reverting

changes) are fast, because there is no need to communicate with a
central server.

 Communication is only necessary when pushing or pulling changes

to or from other peers.
 Version Control

Most version control systems involve the following concepts, though

the labels may be different.

Commit 
A commit (checkin, ci or, more rarely, install, submit or record)
occurs when writing or merging a copy of the changes made to the
working copy into the repository.

Change 
A change (or diff, or delta) represents a specific modification to a
document under version control.

Change list 
On many version control systems, a changelist, change set, or
patch identifies the set of changes made in a single commit.

Checkout 
A check-out (or co) creates a local working copy from the
repository. A user may specify a specific revision or obtain the latest.
 Version Control

Working copy
The working copy is the local copy of files from a repository, at a
specific time or revision. All work done to the files in a repository is
initially done on a working copy, hence the name. Conceptually, it is
a sandbox

Conflict 
A conflict occurs when different parties make changes to the same
document, and the system is unable to reconcile the changes. A user
must resolve the conflict by combining the changes, or by selecting
one change in favor of the other.

Delta compression 
Most revision control software uses delta compression, which retains
only the differences between successive versions of files. This allows
for more efficient storage of many different versions of files.

Head 
The most recent commit.
 Version Control
Branch 

A set of files under version control may be branched or forked at a

point in time so that, from that time forward, two copies of those
files may develop at different speeds or in different ways
independently of the other.
 Version Control

Merge
 
A merge or integration is an operation in which two sets of
changes are applied to a file or set of files.

 This may happen when one user, working on those files, updates
their working copy with changes made, and checked into the
repository, by other users. Conversely, this same process may
happen in the repository when a user tries to check-in changes.

 It may happen after a set of files has been branched, then a

problem that existed before the branching is fixed in one branch and
this fix needs merging into the other.

 It may happen after creating a branch; followed by independent

development of the code in those files; and finally incorporating
those changes into a single, unified trunk.
 Version Control

Promote 
The act of copying file content from a less controlled location into a
more controlled location. For example, from a user's workspace into
a repository, or from a stream to its parent.

Repository 
The repository is where files' current and historical data are stored,
often on a server. Sometimes also called a depot

Update 
An update (or sync) merges changes made in the repository (by
other people, for example) into the local working copy.

Reverse Integration
The process of merging different team branches into a main trunk of
the versioning system

Trunk
The unique line of development that is not a branch
 Change Control

 For a large software engineering project, uncontrolled change

rapidly leads to chaos.

 The Change control process is illustrated systematically in Figure 3

 A change request is submitted and evaluated to access the

technical merit, potential side effects, overall impact on other
configuration objects and the projected cost of change

 The results of the evaluation are presented as a change report,

which is used by a Change Control Authority or Change Control Board
(makes a final decision on the status and priority of the change)

 An Engineering Change order(ECO) is generated for each approved

change

 The ECO describes the change to be made, the constraints that

must be respected and the criteria for review/audit
 Change Control

 The object to be changed is “Checked out” of the project database,

the change is made and appropriate SQA activities are applied

 The object is then “Checked in” to the database and appropriate

version control mechanisms are used to create the next version of
the software

 The “Check in” and “Check out process implements two important
elements of change control

 Access Control
Access control governs which software engineers have the authority
to access and modify a particular configuration object

 Synchronization Control
Synchronization control helps to ensure that parallel changes
performed by two different people don’t overwrite one another

 Access and Synchronization control flows are illustrated in next

slide
Access and Synchronization Control
 Change Control

 Based on the approved change request and ECO, a software

engineer checks out a configuration objects

 An access control function ensures that the software engineer has

authority to check out the object

 Synchronization control locks the object in the project database so

that no update can be made to it until the currently checked out
version has been replaced

 Note that other copies can be checked out but other updates cannot
be made

 A copy of the baselined object, called the extracted version, is

modified by the software engineer
Change Request
Change Request Form
Version and Change Tracking
Change Control -- Example
 Version and Change Tracking
Propagating Change
 Version and Change Tracking

Diff Workflow
Version and Change Tracking-- Repository Systems

Revision History
Version and Change Tracking-- Repository Systems

Revision Graph
Version and Change Tracking-- Repository Systems

Roll Back
Version and Change Tracking-- Repository Systems
Semantics of Changes

 History of the system is a list of changes

 Recording changes

 Change Sets (group file changes according to task)

Version and Change Tracking-- Repository Systems

Change Sets
Version and Change Tracking-- Repository Systems
General Workflow of Developer
 Version and Change Tracking
General Workflow of Developer
Version and Change Tracking Tools
 Configuration Audit
 A software configuration Audit assesses a configuration object for
characteristics.

 The Audit asks and answers the following questions:

 Has the change specified in the ECO been made?

 Has the software process been followed and have software engineering
standards been properly applied?

 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 SCI’s been properly updated?

 Status Reporting
 Configuration status reporting is an SCM task that answers the
following questions:

 What happened?
 Who did it?
 When did it happen?
 What else will be affected?

 Each time an SCI is assigned new or updated identification, a CSR

entry is made.

 Each time a change is approved by CCA, a CSR entry is made

 Each time a configuration audit is conducted, the results are

reported as part of the CSR task

 CSR report is generated on a regular basis and is intended to keep

management and practitioners appraised of important changes

 CSR helps to improve communication among employees with in an

organization