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.

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.

Bersoff, et al, 1980

OverviewSoftware evolution Configuration managementChange control boardChange managementAuditing and status accounting

The Software Configuration

programs documents

dataThe pieces

IntroductionIdeal:

Software is developed from stable/frozen requirementsAs it is easier to hit a stationary target than a moving target

Reality:Not applicable for most real-world systems

The only constant is “CHANGE”An effective software project need to have a strategy to tackle “CHANGE”

What Are These Changes?

data

otherdocuments

codeTest

ProjectPlan

changes in technical requirements

changes in business requirements

changes inuser requirements

software models

Software Evolution

Software evolves over a period of time

Many different items are produced over the duration of the projectDifferent versions are producedTeams work in parallel to deliver the final product

Software evolution implies a constantly changing system

Change & SCM

Software Engineering

a TQM foundation

procedures

methods

tools

SCM• identification• version control• change control• auditing• reporting• construction

Nature of Software Changes

The four aspects of software evolution are:

1. Corrective changes2. Adaptive changes3. Perfective changes4. Preventive changes

Corrective Changes

Required to maintain control over the system’s day-to-day functionsThese changes are made as faults (or) bugs are found during the development timeSome changes may be long-term and fundamental, some may be patches to keep the system in operation (emergency fixes)

Adaptive Changes

Essentially maintaining control over system modificationsAs one part of the system changes, other impacted areas will need to be updatedExamples

Database upgradesUse of a new compiler or development tool

Perfective Changes

Perfecting existing acceptable functionsThe domain of Refactoring designs falls into this categoryPerfective changes are done to increase the long-term maintainability or elegance of the solution

Involves changes to design or data structures for better efficiencyUpdates to documentation to improve its qualityEnhancing the code to make it more readable

Preventive Changes

Preventing the system performance from degrading to unacceptable levelsInvolves alterations made to ensure that the system has a defense against potential failuresExample:

Adding extra redundancy modules to ensure that all transactions are properly logged

Types of ChangesThe typical distribution of these changes is (from Lientz & Swanson 1981):

Perfective (50%)Adaptive (25%)Corrective (21%)Preventive (4%)

These figures change depending on the system and project

Changes and ControlIf changes are not controlled in a project – things can and will get out of handThe issue of change management is even more important when multiple people work on a project as well as on the same deliverableWithout proper strategies and mechanisms to control changes – one can never revert back to an older more stable copy of the software

every change introduces risk into the project

The facts:Change is unavoidable in softwareChanges need to be controlledChanges need to be managed

The solutionSoftware configuration management (SCM)

So what is the answer?

Software Configuration Management

SCM can help determine the impact of change as well as control parallel developmentIt can track and control changes in all aspects of software development

RequirementsAnalysisDesignCodeTestsDocumentation

Terminology Review

Configuration items - any single atomic item for which changes need to be tracked

Source code fileThe project planThe documentation standard…

Baseline - A product that has been formally approved, and consists of a well-defined set of consistent configuration items

Version Allocation/1

Once a configuration item (CI) has been identified – a proper version number must be allocatedThe best option is to start with a major-minor versioning scheme

Major version numbers are between 0 – nMinor version numbers should be between 0 – 100

Version Allocation/2Examples:

Report.Java (version 1.23)• Major version: 1.0• Minor version: 23 (indicative of number of

revisions to this file)

Project plan (version 6.34d)• Major version: 6• Minor version: 34• The “d” is indicative of “draft”

Versioning scheme is developed by the company to suite their needs

Version Allocation/3

Often many companies prefix the configuration item based on its type.

Documentation may be prefixed “doc”Source code can be “src”Example: doc-pmp-2.34• Project management plan document

(version 2.34)

Version Allocation/4

New versions of software can be:Maintenance releasesMinor upgradesTechnology refresh or major upgradesTechnology insertion

Deltas Vs Separate Files

After the initial baseline has been established – the item is said to be under SCM.Changes can be tracked as:

Deltas: only the changed portion is storedSeparate file: changes are stored in a new file

Deltas work best for text filesSeparate files is a good idea for binary file formats.

Change Control

STOP

Change Management – 1For best results changes should be handled formally

A change control board (CCB) is necessary

CCB consists of all key stakeholders

CustomersDevelopersDesigners and architectsManagementBusiness strategists and financiers

Change RequestChanges are required because:

A problem is discovered (bug?)An enhancement is required

Once a change is required – a “change request” is raisedA change request (CR) will outline:

Current operation, nature of problem/enhancement, expected operation after system is changed

Auditing

SCIs

ChangeRequests SQA

Plan

SCM Audit

Configuration Auditing – 1Key philosophy is “trust by verify”Configuration auditing is a process to:

Verify that the baseline is complete & accurateCheck that changes made and recordedDocumentation reflects updates

Audits can be rigorous, or on a random set of configuration itemsA regular audit is required to ensure that SCM is working efficiently:

Can reveal weaknesses in processes, tools, plans as well as resources

Configuration Auditing – 2

The two main types of audit are:Physical audit: are all identified items have a correct version and revision, this helps us remove old and unnecessary items. Functional audit: verifies that the items under SCM satisfy defined specifications.

Roles and Responsibilities…

Configuration managerResponsible for approving configuration itemsResponsible for development and enforcement of proceduresApproves STM (ship to manufacture) level releaseResponsible for monitoring entropy

Change control boardApproves and prioritizes, or rejects change requests

Roles and Responsibilities…

Software engineersResponsible for identification and versioning of configuration itemsCreate promotions triggered by change requests or the normal activities of development. Update the items to incorporate requested changes – they also resolve any merge conflicts

StandardsApproved by ANSI:

IEEE 828: software configuration management plansIEEE 1042: guide to software configuration management

ToolsExamples:

Microsoft – VSS, Team foundation

CVS(Concurrent Versions System)

Functions of a Repository

Access to repository is controlled by a security policy (in CVS a username/password)After a user is logged into the repository they can:

Check-out a file for useCheck-in a changed file back into the repositoryTag the repository at a certain date/timePlace a new file into the repository

Regression TestingInitial Version (v3.2)

Changed Version

Test Case

Faults

Verifies

Reveals

MinorModifications

fixesVerifies

Regression Testing

Benefits of SCMA modern CM solution can provide companies with many benefits such as :

Providing integrity and hence improving the complete software development and maintenance cycle.

Parallel planning and development. Offshore, distributed development.

Management of change complexity and its evolution.

Making testing and QA structured and easier.

Removing error-prone steps from product release management.

Thank you!