0% found this document useful (0 votes)
144 views50 pages

Software Configuration Management

This document provides an overview of software configuration management (SCM). It defines SCM as the process of managing changes to software throughout its development. The key aspects covered include identifying configuration items, controlling changes through baselines and change requests, auditing changes, and reporting on the configuration status. Basic SCM terminology is defined, such as configuration items, baselines, versions and releases. Standards for SCM processes from IEEE and MIL are also briefly outlined.

Uploaded by

Muhammad Naeem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
144 views50 pages

Software Configuration Management

This document provides an overview of software configuration management (SCM). It defines SCM as the process of managing changes to software throughout its development. The key aspects covered include identifying configuration items, controlling changes through baselines and change requests, auditing changes, and reporting on the configuration status. Basic SCM terminology is defined, such as configuration items, baselines, versions and releases. Standards for SCM processes from IEEE and MIL are also briefly outlined.

Uploaded by

Muhammad Naeem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 50

Software Quality Assurance

Software Configuration
Management

Outline

What is Software Configuration


Management (SCM) and Why?
Basic Terminologies
SCM Activities
SCM Tools
SCM Standards
SCM Forms
SCM

Software Quality Assurance

What is SCM and Why?

Why SCM?
Multiple teams are working on software
And that software is changing
More than one version of the software
has to be supported:

Released systems
Custom configured systems (different
functionality)
System(s) under development

Software must run on different


machines and operating systems
SCM

Why SCM?
So, we need a mechanism to:

Avoid the document override.


Minimize the confusion.
Uniquely identify every version of
every product or configuration item.
Retain historical versions of software
/ documents.
Provide an audit trail of all changes.
SCM

Why SCM?
and
SCM does all this

and much more.


SCM

Change

There is nothing permanent except


change

(Heraclitus)
SCM

Change
First Law of System Engineering
states:
No matter where you are in the
system life cycle, the system will
change, and the desire to change
it will persist throughout the life
cycle
SCM

Origin of Change
Changes will occur at any time,
for any reason. The major reasons
are:

New business or market conditions


New customer needs
Business growth or downsizing or
reorganization
Budgetary or scheduling constraints
SCM

Configuration
Management
This change must be managed and controlled
in order to improve quality and reduce error.
Software Configuration Management (SCM)
is a set of activities that have been developed
to manage change
throughout the software life cycle.
SCM

10

SCM
SCM is the art of identifying,
organizing and controlling
modifications to the software
being built by a project team.

SCM

11

Software Quality Assurance

Basic Terminologies

Output of Software Process


Programs
Source Code
Exe
Data
Internal
External

Documentatio
n
Technical
End user

SCM

13

Software Configuration
Item

Information produced as a part of


the software process is called
Software Configuration Item
(SCI).

SCM

14

Software Configuration
Item

An SCI can be a single section of a


document, for example, a test case
or
The entire document, for example,
the suite of test cases.
Defining the SCI is the major
activity in SCM.
SCM

15

SCI Examples

SRS
Design Specification
Project Plan
Test Plan
Test Cases
User Manuals
Etc..
SCM

16

Software Configuration
Object
Collection of closely related SCIs
An SCO has

A name
Attributes
And relationships with other SCOs
SCM

17

SCO Examples

Test Plan, Test Procedures and


Test Data are SCIs, all related to
testing.
The are grouped to form a single
SCO, called
Test
Specification
An SCO
Test Specification
Test Plan
Test Procedure
Test Cases
SCM

SCIs

18

Relationship b/w SCOs


The relationship between SCOs is
shown by two types of arrows.
Curved Arrow

1.

Indicates compositional relationship

Double Headed Straight Arrow

2.

Indicates an interrelationship

SCM

19

Relationship b/w SCOs


Data Model
Design Specification

Design Data
Architectural Design
Module Design
Interface Design

Components

Interface
Algorithm
.

Test Specification

Source Code

Test Plan
Test Procedure
Test Case

SCM

20

Baseline
A specification or product 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 control procedures.
SCM

21

Baseline
A specification or product 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 control
procedures.
SCM

22

Baseline
A specification or product 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 control
procedures.
SCM

23

Baseline
A specification or product 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 control
procedures.
SCM

24

Project Database

Formally reviewed SCIs are placed


in a database, called Project
Database, Project Library or
Software Repository.
SCM control procedures governs
over Project Database. That is
Changes are made through proper
control and change procedures.
SCM

25

Software Quality Assurance

SCM Activities

SCM Activities
1. IDENTIFICATION

4. STATUS
REPORTING

2. CONTROL

3. CONFIGURATION
AUDIT
SCM

27

Configuration
Identification
The purpose of configuration
identification is to ensure that all
of the products to be controlled:

are uniquely named,


have a point established at which
they will be baselined,
have an identified owner.
SCM

28

Configuration
Identification

Each SCI must be named and


identified as objects.
An SCO can be a Basic Object or
Aggregate Object (consisting of
multiple Basic Objects).
Each SCO has a list of data items

The SCI type (Program, Data, Document)


Project Identifier
Version Number
SCM

29

Release, Version and


Edition

Release: A primary, or formal,


issue. Usually represents a
baseline.
Version: Updates to a release.
Represent significant changes, but
not wholesale modification or
replacement.
Editions: Re-issues of a version with
minor changes.
SCM

30

The 3 digit scheme

A 3 digit scheme is quite


common:
McAfeeStinger10.3.6
Release

Version

SCM

Revision/
Edition

31

SCM Activities
1. IDENTIFICATION

4. STATUS
REPORTING

2. CONTROL

3. CONFIGURATION
AUDIT
SCM

32

Configuration Control
Version Control

Combines procedures and tools to


manage different versions of
configuration objects
Constructs appropriate variants

Change Control

Ensures that only approved changes


are made to the baseline.
SCM

33

Change Control

All suggested changes should be


proposed in a formal manner in a
Configuration Change Request (CCR)
form.
The product owner and Configuration
Control Board (CCB) will review
suggested changes and assess impact
on other configuration items, costs,
schedules, etc, ...
SCM

34

Change Control Process


Evaluation

Change
Report

Change Control
Authority

Change
Request

Chang
e?

Request Denied

Accepted
ECO

Change
Requester

Project
Database

Access
&
Synch.
Control

Persons Need to Know

Make the Change

Audit

Reporting

SCM

35

Access & Sych. Control


Check
-in
Modified SCO,
Audit Info.

Software
Engineer

SCO (extracted
version)

Un-lock

Acces
s
Contro
l
Lock

SCO
(baselined)

Project
Database

SCO
(baselined)

Check
-out

SCM

36

SCM Activities
1. IDENTIFICATION

4. STATUS
REPORTING

2. CONTROL

3. CONFIGURATION
AUDIT
SCM

37

Configuration Audit

How to ensure change has been


properly implemented:
1. Formal Technical Review
2. Software Configuration Audit

Conducted by the Software Quality


Assurance group

SCM

38

SCM Activities
1. IDENTIFICATION

2. CONTROL

4. STATUS
3. CONFIGURATION
REPORTING
AUDIT
SCM

39

Configuration Status
Reporting
A Configuration Status Report
(CSR) is generated on regular
basis and is intended to keep

management and
practitioners appraised of important
changes.

Also known as Configuration


Status Accounting (CSA)
SCM

40

CSR Information
A CSR gives the following
information:

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

In large projects, an online


database of CSRs is maintained.
SCM

41

Software Quality Assurance

SCM Tools

SCM Tools

Many tools are available in the


market to help and manage
change and control mechanism.
For example PC-RCS and CVS and MS
VSS.

Microsoft Visual Source Safe (VSS)


is commonly used.
SCM

43

Software Quality Assurance

SCM Standards

SCM Standards
IEEE Std 828-1998

IEEE Guide to Software Configuration


Management Plan.

IEEE Std 1042-1983

IEEE Guide to Software Configuration


Management.

MIL STD 483

Military Standard for Software Configuration


Management.
SCM

45

IEEE Std 828-1998


Introduction

1.

Describes purpose, scope of application,


key terms and references

Management (WHO?)

2.

Identifies the responsibilities and authorities


for accomplishing the planned configuration
management activities

Activities (WHAT?)

3.

Identifies the activities to be performed in


applying to the project.
SCM

46

IEEE Std 828-1998


Schedule (WHEN?)

4.

Establishes the sequence and coordination of


the SCM activities with project mile stones.

Resources (HOW?)

5.

Identifies tools and techniques required for


the implementation of the SCMP

Maintenance

6.

Identifies activities and responsibilities on


how the SCMP will be kept current during the
life-cycle of the project.
SCM

47

Software Quality Assurance

SCM Forms

SCM Forms

Software Change Request Form


Software/Document Revision
History Sheet
---Forms Handouts ---

SCM

49

Software Quality Assurance

Feel free to ask!


Thanks!

You might also like