SQM – Session 3Software Configuration

Management

Objectives What is Software Configuration Management

Illustrate the need for Software Configuration

Management

Present predicted results from implementing

Software Configuration Management

Provide a brief description of the key SCM

activities and concepts

SCM Tools

SCM• Configuration

The arrangement of a computer system of component as defined by the number, nature, and interconnections of its constituent parts

• Configuration Management

A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, and control changes to those characteristics,report change processing and implementation status,

and verify compliance with specified requirements

Need for SCM

Number of communication channels increase exponentially with number of team members-

the number of coordination problems also increase exponentially with the project size.

Software is Easy to Copy Changes Staff Turnover

Resulting Problems Listing seems OK; program does not work Works in Bombay, misbehaves in Delhi We had customized for this client, how do we install

the upgrade now? I had fixed this bug last month, how did it

reappear I haven’t changed the program. Why is it now

blowing up? Which is the latest source ? I need to put a patch.

Resulting Problems -2

In the last month, user asked for this change and now she does not want it

Where did Anil leave the programs he was working Where did Anil leave the programs he was working on?

Software Configuration Management

SCM addresses all the issues!!

Key SCM activities• Configuration Identification

Selection of the configuration items for a system and recording their functional and physical characteristics

• Baselining

A item that has been formally reviewed and agreed upon, that thereafter serves as the basis further development, and that can be changed only through formal change procedures

• Change Control

Evaluation,coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.

Key SCM activities - 2• Status Accounting

Recording and reporting of Information needed to manage a configuration effectively. Includes a listing of the approved configuration identification, the status of the configuration, and the implementation status of approved changes.

• Configuration AuditVerifying that all required configuration items have

been produced, that the current version agrees with the specified requirements, that the technical documentation completely and accurately describes the configuration items and that all change requests have been resolved.

Key SCM activities - 3

• Subcontractor Control (If applicable) Evaluation,coordination and approval or disapproval of all changes submitted by the subcontractor to approved configuration documentation and monitoring of the subcontractor’s performance on CM

function.

Configuration Identification

Configuration Identification

Identifying the structure of the software system

Identifying all related software life cycle work products

providing a unique identifier for each of those work products

Supporting traceability between the software and all other related software products.

Configuration Identification

• An organisation and/or project should identify which work product are to be placed under configuration Management

• The criteria for which items are selected should be documented and made available to all

affected groups that are supporting the software project

Examples of Configuration items

• Examples of work products that may be identified to be placed under configuration control include:

• Requirement specification compilers• development plan operating systems• architecture specification Linkers/Loaders• Interface specifications procedure languages• design specification shell scripts• code modules other related support tools• Test plans third party tools• test procedures project plans• user documentation quality plans• development procedures configuration management plans• standards logical data structures• data dictionaries user interface files, data• system build files Installation / configuration files

Structures in software development process

• There are two structures that SCM is concerned with

• Problem solving structure

- The system concept evolves through the lifecycle by successive refinement and elaboration

• Product system structure

- The system is composed of subsystem components, which are themselves composed of subsystem components

Configuration Items and Versions

• A configuration item is a work product (documents, code unit test etc.) explicitly based under configuration control

• Each time a configuration item is revised and replaced under configuration control, a new version is created.

• Branch versions are also called Variants

• A configuration is a collection of configuration item versions that are put together( to form a module, a subsystem a product, etc..)

Versions of configuration Items• Version

- Defined state of an object at a particular time(snap shot)

- Replace a previous version when that object has been further developed

• variant - One of several versions of an item that exist at the same time

- Item needs to meet similar but different requirements at the same time(different hardware platforms

Baselining

Baselining

A base line is an approved snapshot of the system at appropriate points in the development life cycle.

A baseline could be

- Specification

- Product that has been formally reviewed and agreed upon

A partial system

The Value of Baselining• Change is a fact of line in software development

– Customers want to modify requirements– Developers want to modify the technical approach– Management wants to modify the project approach

• Why all of this modification?– As time passes all parties know more

• about what they need

• which approach would be best

• how to get it done and still make money

– The additional knowledge becomes the driving force behind most changes

• Most change requests are justified!!!

Baselining • The fundamental success of any development effort

is dependent on well-defined reference points….against which to specify requirements, formulate a design, and specify changes to these requirements and the resultant designs.

• The term baseline is normally used to denote such a reference point

• A baseline is an approved snapshot of the system at a given point in its evolution

•

Baselining-2

• A baseline establishes a formal base for defining subsequent change

• Without this line or reference point the notion of change is meaningless

• The items in the baseline form the basis for the work in the next phase of the software development cycle

• The items of the next baseline are measured and verified against previous baselines before they become baselines themselves

Additional Baselines• The project leader may choose to defines or

create additional baselines on his project to create points of visibility or stability during development

• This may be particularly appropriate if an incremental development approach is adopted or if the customer demand it

Summary

• Baselines are created to establish visibility and stability within a project from which to move forward.

– The high level design baseline for instance is a definition of the system architecture from which detailed designs can be produced.

• A change to baseline is made with a change request because it is likely to involve new agreements/contracts with other affected groups

– It may also have an effect on work that has already been completed in working from the original baseline.

Configuration Change Control

Configuration Change Control• Establishing a change control process that

specifies :

- Who can initiate the change request

- The individuals, group, or groups who are responsible for evaluating, accepting and tracking the change proposals for the various baseline products

- The “change impact” analysis expected for each requested change

- How the change history should be kept

Need for Change Control

• In the ideal world, once a configuration item was fully approved there would be no need to change

• In the real world new versions of a configuration item are needed for a variety of reasons

– The requirements for the system change– The boundaries between items in the design

hierarchy changes• The precise interface between items may need to be renegotiated

as software is designed and written

The Need for Change Control-2

• The specification of an item is incomplete or wrongly interpreted

• An error is found that was not detected during the configuration items review

• The software environment changes in a way that necessitates change

• In each case, new version of a configuration item is needed which supersedes the earlier version

• Replacing one version of a configuration item with a better one is the objective of all change

Without Change Control• Without change control a software engineer

could make an important change to a configuration item or its interfaces without a lot of extra work and red tape

• But no record would be kept for :– What the change was and why the change was requested

– Who wanted the change made

– Who approved the change

– Who made the change

– Who verified the change

Without Change Control- 2

• And it would be hard to fine out

“why doesn’t my software link this morning it linked last night

“why does this regression test fail now? It worked yesterday !”

Why does the product behave this way now? It didn’t before!”

Why are we running out of memory now? We did not have that problem yesterday

Change Control

• All changes made to the configuration management baselines or baseline software configuration items should be done according

to a documented change control process

• The change control process should specify

Who can initiate

Change Management Process

P en d in g

N ew p rod u c t re lease m ad e

C h an g ed item s ch ecked in

con fig u ra tion au d it ca rried ou t

C h an g e m ad e; Q C ac tivit ies carried ou t

C on fig u ra tion item s ch ecked ou t

C on fig u ra tion item s , tasks , Q C req u ired is d ocu m n en ted

C h an g e ord er p rep ared

C C B A p p roved R ejec ted

C h an g e req u es t reviewed fo r ap p rova l

C h an g e req u es t eva lu a ted

C h an g e req u es t d ocu m en ted

Some Good Practices

• Keep version history in the configuration item

• Item to contain exact item name, version number , date

• Identify configuration items to be tracked

Configuration Management Status Accounting

Status Accounting

An ounce of derivation is worth a pound of analysis- Wayne Babich

Status Accounting

• Maintaining a continuos record of the status and history of all baselined items and proposed changes to them.

• Reports on the traceability of changes to the baseline throughout the software life cycle.

• Answers the questions

- What changes have been made to the system? - What changes remain to be implemented?

Status Accounting

• The mechanism that records how a system evolves and relates to the baseline and any written agreements at any point in time

• The purpose of software configuration status accounting is to maintain a continuous record (changes and actions) of all baselined items.

Configuration Management Reports

• CM reports should be generated on a periodic basis and distributed to all appropriate groups and individuals.

• The configuration management status reports may include:– SCCB meeting minutes– Change request summary and status– Trouble report summary and status – Summary of changes made to the software baselines and

their frequency– Revision history of all configuration items – Results of software baselines audits

Status Accounting Uses• Configuration Management Status Accounting provides

visibility into the system evolution by recording and reporting the status of all configuration items and the status of all requests for change

• Questions that Configuration Management Status Accounting should be able to answer include:– What is the status of an item ?– A programmer may want to know whether a specification

has been fully approved – A programmer may want to know whether a subsystem has

been tested so that the programmer can test his modules which interface with that subsystem

Status Accounting Uses-2 – A project leader will wish to track the progress of a

project as items are developed, reviewed , tested and integrated

• Has change request been approved for rejected by the SCCB?– The originator of a change request will want to know if

the SCCB has approved or rejected the request

• Which version of an item implements an approved change request?– Once a requested enhancement of a library routine is

implemented, the originator and other developers will want to know which version of the routine contains the enhancement

Summary• Configuration management status accounting is the means by which key

project or system information can be communicated to everyone

• Project members can easily determine which configuration item should be used,whether it is subject to a change request, and what a build consists of.

• Project Leaders can easily determine:– What Cls have passed review,– Which changes have been completed,– Which changes are still in progress,– How many changes have been accepted,– Which modules are the most volatile ,– What a build consists of– What has been delayed to the next release.

Configuration Audits

Audit Objectives

• Answer the questions:– Does the system satisfy the requirements?– Does the documentation represent the system as

built?– Are all changes incorporated in this version?– Are only approved changes incorporated in this

version?

• How can one ensure the product’s integrity?

Product Integrity• A software product that has product integrity is one that:

– Fulfills customer needs – Can be easily and completely traced through its lifecycle – Meets specified performance criteria– Meets cost expectations– Meets delivery expectations

• If the software lifecycle is difficult or impossible to trace– Either the software must be forever frozen– Each change that is applied to evolve it is high risk with a small

probability of a good return on investment

Consistency• In order to achieve product integrity, consistency must be maintained across

the software life-cycle work products including:– Software plans

– Process descriptions

– System requirements allocated to software

– Software requirements

– Software design

– Code

– Test plans

– Test Specifications

– Test Procedures

Consistency-2• Minimal requirements to maintain consistency include:

– Changes to the software life-cycle work products, plans, process descriptions and activities are proposed analyzed, and incorporated as appropriate

– The impact of any change request is made before the change is accepted

– Changes to the system requirements allocated to software are changed before subsequent software activities and work products are changed

• Changes to all affected software products,plans,process descriptions ,and activities are made before the change request implementation is considered complete

Configuration Audits• Changes are negotiated with and communicated to all affected

groups• Changes are tracked to completion• A software configuration audit should periodically be performed to

ensure that the SCM practices and procedures are rigorously followed

• General ground rules for SCM audits:– A documented project SCM plan is used as the basis for all SCM audits – There is adequate preparation for the audit– The integrity of the software baselines is assessed

Configuration Audits-2-The structure and facilities of the configuration management library system are reviewed

• The completeness and correctness of the software baseline library contents are verified

• The accuracy if the implementation of the changes to the baselines is verified

• A successful software configuration audit should be performed before every major baseline change

• Auditing also entails ensuring that changes made to an existing baseline, are implemented as intended

Configuration Audits-3• Software configuration auditing is continuous,with

increased frequency and depth throughout the development lifecycle

• SCM audits are highly efforts requiring software expertise and knowledge at a level equal to or in excess of that possessed by the development team

PCA/FCA

Summary: CM functionsWhat is System The system Consists of the Configuration following baseline documents and

products..

How are changes The steps to process changes are ... to the Configuration

Controlled?

What changes have The system configuration and relatedbeen made to the Changes At this line are the combination system? Of the following baseline changes, pending

Changes...

Does the system The system as currently built differs fromsatisfy the the baseline approved changes as requirements ? follows….

Identification

control

Status accounting

Auditing

Barriers to SCM

• Schedule pressure– fixes being incorporated as the product is going out the

door

• Lack of automated support

• Individual’s belief that they don’t need CM

SCM Tools• Platinum’s Harvest

• Pure Atria’s Clear Case

• Countinuus’ Continuus

• SVN

• Intersolv’s PVCS

• MKS’s Source Integrity

• Microsoft’s Visual source safe

• Perforce Software’s Perforce

High End

Low End

High End

Low End

Bad Excuses• We apply CM only to source code

• CM is not applicable because using the latest iterative, concurrent, rapid, spiral, evolutionary life cycle model

• CM hinders persons with initiative from making a quick correction

• CM hinders creativity

• We do not have a change request form because the customer doesn’t want it

• Our CASE tools will automatically do CM

• CM responsibility belongs to our customer

• CM is a clerical task that does not require much skill

• Design documents are not in CM because we want the flexibility to change design easily

• We don’t track change history in data dictionary because our CASE tool has no provision to do it.

Assignment-Self Study1. Understand the following terms with respect to

Configuration Management, how it is performed in the SCM Tool you use in your projectBasic Setup :-Repository (repo),Server/Client, Working Set/Workin Copy,.

Trunk/Main, workspace

Basic Actions: Add/Revision, Head,Check out/Check in,Checkin Message

Changelog/History/Update/Sync, Revert

Advanced Actions : – Branch: Diff/Change/Delta

– Merge (or patch): Conflict:

– Resolve:.

– Locking:.

– Breaking the lock: Check out for edit:

2. Study the SCM Plan Content of your project .