Software Configuration Management

The First Law

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.

What Are These Changes?

changes in business requirements changes in technical requirements changes in user requirements

other documents

software models Project Plan data Test code

Software Configuration Management (SCM)

The process of identifying, organizing, and controlling changes to the software during development and maintenance.
j SCM is a support activity that makes technical

and managerial activities more effective

jSCM operates throughout the SW life-cycle

Causes of Change
j Evolutionary changes the system evolves as it passes through various stages in the development cycle j Revolutionary changes such change is caused by the system being unable to satisfy the users requirements or the customers or producers expectations

Why Products change ?

j Requirements change during and after

development
j Errors are found and need correction j Variants are needed

Problems of Change
Which component ? Which version ?
j Double (or multiple) maintenance j Updates to shared data j Simultaneous update

SCM Functions
j Identification of software items and products j Definition of Baselines j Access controls j Progressing defect reports j Progressing change requests j Recording item status j Controlling releases (versions and variants) j Reporting

SCM Tasks
j Configuration identification j Configuration control j Status accounting j Configuration audit

Some Definitions ...

Development item Configuration item (CI) item not yet approved, can be informally changed an approved and accepted deliverable, changes done through formal change control procedures

Typical SW Configuration Items (CIs)

j j j j j j j j j j

Management plans Specifications (requirements, design) User documentation Test design, case and procedure specifications Test data and test generation procedures Data dictionaries and databases Source code, executable code Libraries Maintenance documentation Support software

The Software Configuration

programs

documents

The pieces data

12

The SCM Process

Software Vm.n reporting

configuration auditing version control change control identification

SCIs

13

Milestones and Baselines

Milestone A milestone is the end of a stage or phase of a project at which one or more deliverables are actually delivered. Baselines A baseline is that collection of items which when complete indicates that a milestone in the development process has been reached.

Baselines
j The IEEE (IEEE Std. No. 610.12-1990)

defines a baseline as:

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.

j a baseline is a milestone in the development

of software that is marked by the delivery of one or more software configuration items and the approval of these SCIs that is obtained through a formal technical review
15

Typical Baselines
Phase Feasibility study Requirements defn. SRS, Interface spec. Detailed design Source and Object code User manuals Test documents Installation Baseline
Functional baseline Allocated baseline Design baseline

Product baseline Operational baseline

Baselines
j Baselines serve as the basis for further

development
j Baselines can be changed only through

formal change control procedures

j Only items that have been approved and

obtained through a formal technical review are accepted into the baseline.

Configuration Identification
j Identify what the different baselines will

consist of
j Set labelling and identification conventions

for the CIs

Basic CI information
j Item identity j Baseline to which it belongs j Relationships to other items j Version j Variant

SCM Terminology
Version
A SW CI having a defined set of functional capabilities.

Revisions
changes to a version to correct only errors in design logic but does not affect documented functional capabilities since none of the requirements have changed.

Variants
a variation of a version developed to run on different types of HW, or to provide slightly different facilities for different users.

Examples
successive versions 1.1 1.2 1.3 1.4

branching versions (variants) 1.3.1.1 1.3.1.2

1.1

1.2

1.3

1.4

Merging
j Two diverging versions may be merged to

create a single new version combining both set of change requests.

j Merge operations are typically done

interactively with tool assistance

SCM Terminology
Promotion of a CI
A CI may be promoted from one developmental baseline to another to signify a change in a CIs internal development state.

Release
A Release is used to designate certain promotions of CIs that are distributed outside the development organization.

Configuration Control
j Enforces a rigorous change control

mechanism
j Requires formal procedures to request changes carry out impact analysis approve changes carry out changes

SCM Elements
j Component elementsa set of tools coupled within a file

management system (e.g., a database) that enables access to and management of each software configuration item. j Process elementsa collection of procedures and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering and use of computer software. j Construction elementsa set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled. j Human elementsto implement effective SCM, the software team uses a set of tools and process features (encompassing other CM elements)
. 25

The SCM Process

Addresses the following questions j How does a software team identify the discrete elements of a software configuration? j How does an organization manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently? j How does an organization control changes before and after software is released to a customer? j Who has responsibility for approving and ranking changes? j How can we ensure that changes have been made properly? j What mechanism is used to appraise others of changes that are made?
26

Change Management Methodology

j Submission of Change Request (CR) j Technical and business evaluation and

impact analysis j Approval by Change Control Board j Engineering Change Order (ECO) is generated stating changes to be made criteria for reviewing the changed CI j CIs checked out j Changes made and reviewed j CIs checked in

Change Control Board

j A group consisting of representatives of user,

customer, producer.
j Responsibilities:

to approve, monitor and control baselines to approve, monitor, and control changes to authorise changes j CCB concerns in change approval
technically ok solution, cost, schedule, configuration of the whole system, user satisfaction

Change Control ProcessI

need for change is recognized change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed change control processII process

29

Change Control Process-II

assign people to SCIs check-out SCIs checkmake the change review/audit the change establish a baseline for testing

change control processIII process

30

Change Control Process-III

perform SQA and testing activities check-in the changed SCIs checkpromote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release

31

Version Control
j Version control combines procedures and tools to manage different

versions of configuration objects that are created during the software process j A version control system implements or is directly integrated with four major capabilities: a project database (repository) that stores all relevant configuration objects a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions); a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

32

Software Libraries
j SW libraries provide the means for

implementing SCM
j The number and kind of libraries will

vary from project to project . It depends on the levels of control needed.

Three Kinds of Software Libraries

Dynamic library (programmers library)
programmers workspace

Controlled library (master library)

used for managing the current baseline(s) and for controlling changes made to them

Static library (software repository)

used to archive various baselines released for general use

Techniques for storing Versions

j Full files j Forward Delta files j Reverse Delta files j The set of differences between two

versions is called a delta.

Forward Delta Files

User CM System foward delta files

Vn version
changes

Vn version

first version

Vn+1 version

Vn+1 version Vn version

Reverse Delta Files

User CM System Vn+1 new recent version reverse delta files

Vn+1 version
changes

Vn version

recent version

Vn version

Status Accounting
j provides a mechanism for administrative

tracking and reporting of all SW items identified and controlled.

j Examples of Status reports:

the status of proposed changes the status of approved changes the baselines and the approved changes associated with each baseline the date when each revision of each CI was recorded deficiencies identified by configuration audit

Configuration Audit
j A configuration audit establishes that

product integrity has been maintained and that changes have taken place in an orderly and controlled manner.
j Audit of the SW product j Audit of SCM activities

Auditing
Change Requests SCIs SQA Plan

SCM Audit

40

Status Accounting
Change Requests SCIs Change Reports ECOs

Status Accounting Reporting

41

Physical Configuration Audit

consists of determining that all items identified as being part of the configuration are present in the Product baseline it must also establish that the correct version and revision of each part are included in the product baseline and that they correspond to information contained in the baselines configuration status report.

Functional Configuration Audit

it verifies that each CI in the product has been tested to determine that it satisfies the functions defined in the specifications or contract(s) for which it was developed.

Organising for SCM

Roles: j Configuration manager
j Change Control Board

includes representatives of - user - customer - developer

SCM Plan
The SCM Plan is prepared in Project Initiation phase. It documents - what SCM activities are to be done - how they are to be done - who is responsible for doing specific activities - when they are to happen - what resources are required

SCM Tools
Common features of popular PC-based tools (PVCS, MS Visual SourceSafe):
j Support for controlling all types of files

(source code as well as binary) j Managing changes as deltas j Supporting branching and merging j Identifying and re-creating releases j Providing a project view

Intersolv PVCS Version Manager 5.2

j One of the oldest PC-based version control

products j Large installed base j A fairly rich feature set j Interfaces with other third party tools j Gateways to mainframe-based library management systems j Comprehensive security

Microsoft Visual SourceSafe 4.0

j Project support j File sharing j Intuitive GUI interface j Good repository architecture j Powerful security features j Tight integration with Visual Basic and Visual

C++ development tools

SCM Tools for Unix

j SCCS (Source Code Control System) manages changes to text files uses a single file (s-file) to store first version and successive forward deltas j RCS (Revision Control System) manages changes to text files uses reverse deltas to store versions

SW Configuration Management Plan

-- IEEE Standard 828-1990 for SCM Plan 1. Introduction 2. SCM Management
2.1 Organization 2.2 SCM Responsibilities 2.3 Applicable policies, directives and procedures

SW Configuration Management Plan

-- IEEE Standard 828-1990 for SCM Plan 3. SCM Activities
3.1 Configuration identification 3.1.1 Identifying configuration items 3.1.2 Naming configuration items 3.1.3 Acquiring configuration items 3.2 Configuration control 3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or disapproving changes 3.2.4 Implementing changes

SW Configuration Management Plan

-- IEEE Standard 828-1990 for SCM Plan (3. SCM Activities)
3.3 3.4 3.5 3.6 Configuration Status Accounting Configuration Audits and Reviews Interface control Subcontractor/Vendor control

4. SCM Schedules 5. SCM Resources 6. SCM Plan maintenance