SOFTWARE CONFIGURATION MANAGEMENT

Read Time:10 Minute, 31 Second

SOFTWARE CONFIGURATION MANAGEMENT

The results of a large software development effort typically consist of a large number of objects,

e.g., source code, design document, SRS document, test document, user’s manual, etc.

These objects are usually referred to and modified by a number of software developers throughout the life cycle of the software.

The state of each deliverable object changes as development progresses and also as bugs are detected and fixed.

The configuration of the software is the state of all project deliverables at any point of time; and software configuration management deals with effectively tracking and controlling the configuration of a software during its life cycle.

As software is changed, new revisions and versions get created. Before we discuss configuration management, we must be clear about the distinction between a version and a revision of a software product.

Software revision versus version

A new version of a software is created when there is significant change in functionality, technology, or the hardware it runs on, etc.

On the other hand, a new release is created if there is only a bug fix, minor enhancements to the functionality, usability, etc.

Even the initial delivery might consist of several versions and more versions might be added later on. For example, one version of a mathematical computation package might run on Unix-based machines, another on Microsoft Windows and so on.

As a software is released and used by the customer, errors are discovered that need correction.

Enhancements to the functionalities of the software may also be needed.

A new release of software is an improved system intended to replace an old one.

Often systems are described as version m, release n; or simply mn. Formally, a history relation is version of can be defined between objects. This relation can be split into two subrelations is revision of and is variant of.

Necessity of Software Configuration Management

There are several reasons for putting an object under configuration management.

The following are some of the important problems that can crop up, if configuration management is not used:

every software developer has a personal copy of an object (e.g. source code). When a developer makes changes to his local copy, he is expected to intimate the changes that he has made to other developers, so that the necessary changes in interfaces could be uniformly carried out across all modules.

However, not only would it eat up valuable time of the developers, but many times a developer might make changes to the interfaces in his local copies and forgets to intimate the teammates about the changes.

This makes the different copies of the object inconsistent.

Finally, when the different modules are integrated, it does not work.

Therefore, when several team members work on developing an application, it is necessary for them to work on a single copy of the application, otherwise inconsistencies may arise.

Problems associated with concurrent access:

Possibly the most important reason for configuration management is to control the access to the different deliverable objects.

Unless strict discipline is enforced regarding updation and storage of different objects, several problems can appear.

Assume that only a single copy of a program module is maintained, and several developers are working on it.

Two developers may simultaneously carry out changes to different functions of the same module, and while saving overwrite each other. Similar problems can occur for any other deliverable object.

Providing a stable development environment:

When project work is underway, the team members need a stable environment to make progress.

Suppose one developer is trying to integrate module A, with the modules B and C; since if the developer of module C keeps changing C; this can be especially frustrating if a change to module C forces recompilation of the module.

When an effective configuration management is in place, the manager freezes the objects to form a baseline.

A baseline is the status of all the objects under configuration control. When any of the objects under configuration control is changed, a new baseline gets formed. When any team member needs to change any of the objects under configuration control, he is provided with a copy of the baseline item.

The requester makes changes to his private copy. Only after the requester is through with all modifications to his private copy, the configuration is updated and a new baseline gets formed instantly.

This establishes a baseline for others to use and depend on. Also, baselines may be archived periodically (archiving means copying to a safe place such as a remote storage), so that the last baseline can be recovered when there is a disaster.

System accounting and maintaining status information:

System accounting denotes keeping track of who made a particular change to an object and when the change was made.

Handling variants:

Existence of variants of a software product causes some peculiar problems.

Suppose you have several variants of the same module, and find that a bug exists in one of them. Then, it has to be fixed in all versions and revisions.

To do it efficiently, you should not have to fix it in each and every version and revision of the software separately.

Making a change to one program should be reflected appropriately in all relevant versions and revisions.

Configuration Management Activities

Configuration management is carried out through two principal activities:

Configuration identification:

It involves deciding which parts of the system should be kept track of.

Configuration control:

It ensures that changes to a system happen smoothly. Normally, a project manager performs the configuration management activity by using a configuration management tool.

In addition, a configuration management tool helps to keep track of various deliverable objects, so that the project manager can quickly and unambiguously determine the current state of the project.

The configuration management tool enables the developer to change various components in a controlled manner.

Configuration identification Project managers normally classify the objects associated with a software development into three main categories

Controlled
Precontrolled
Uncontrolled

Controlled objects are those that are already under configuration control.

The team members must follow some formal procedures to change them.

Precontrolled objects are not yet under configuration control, but will eventually be under configuration control.

Uncontrolled objects are not subject to configuration control.

Controllable objects include both controlled and precontrolled objects. Typical controllable objects include:

Requirements specification document
Design documents
Tools used to build the system, such as compilers, linkers, lexical analysers, parsers, etc.
Source code for each module
Test cases
Problem reports

Configuration management plan is written during the project planning phase. It lists all controlled objects.

The managers who develop the plan must strike a balance between controlling too much, and controlling too little.

If too much is controlled, overheads due to configuration management increase to unreasonably high levels.

On the other hand, controlling too little might lead to confusion and inconsistency when something changes.

Configuration control

Configuration control is the process of managing changes to controlled objects.

The configuration control part of a configuration management system that most directly affects the day-to-day operations of developers.

Configuration control allows only authorised changes to the controlled objects to occur and prevents unauthorised changes.

In order to change a controlled object such as a module, a developer can get a private copy of the module by a reserve operation.

Configuration management tools allow only one person to reserve a module at any time. Once an object is reserved, it does not allow any one else to reserve this module until the reserved module is restored.

Thus, by preventing more than one developer to simultaneously reserve a module, the problems associated with concurrent access are solved.

Let us see how an object under configuration control can be changed.

The developer needing to change a module first makes a reserve request.

After the reserve command successfully executes, a private copy of the module is created in his local directory.

Then, he carries out all necessary changes on his private copy.

Once has satisfactorily completes all necessary changes, the changes need to be restored in configuration management repository.

However, restoring the changed module to the system configuration requires the permission of a change control board (CCB).

The CCB is usually constituted from among the development team members.

For every change that needs to be carried out, the CCB reviews the changes made to the controlled object and certifies several things about the change:

1. Change is well-motivated.

2. Developer has considered and documented the effects of the change.

3. Changes interact well with the changes made by other developers. 4. Appropriate people (CCB) have validated the change, e.g., someone has tested the changed code, and has verified that the change is consistent with the requirement.

The change control board (CCB) sounds like a group of people. However, except for very large projects, the functions of the change control board are normally discharged by the project manager himself or some senior member of the development team.

Once the CCB reviews the changes to the module, the project manager updates the old baseline through a restore operation.

A configuration control tool does not allow a developer to replace an object he has reserved with his local copy unless he gets an authorisation from the CCB.

By constraining the developers’ ability to replace reserved objects, a stable environment is achieved.

Since a configuration management tool allows only one developer to work on one module at any one time, the problem of accidental overwriting is eliminated.

Also, since only the manager can update the baseline after the CCB approval, unintentional changes to the configuration items are eliminated.

Source code control system (SCCS) and RCS

SCCS and RCS are two popular configuration management tools available on most Unix systems.

SCCS or RCS can be used for controlling and managing different versions of text files.

SCCS and RCS do not handle binary files (i.e., executable files, documents, files containing diagrams, etc.)

SCCS and RCS provide an efficient way of storing versions that minimises the amount of occupied disk space.

Suppose, a module MOD is present in 3 versions—MOD1.1, MOD1.2 and MOD1.3.

Then, SCCS and RCS stores the original module MOD1.1 together with changes needed to transform MOD1.1 into MOD1.2 and MOD1.2 to MOD1.3.

The changes needed to transform each baselined file to the next version are stored and are called deltas.

The main reason behind storing the deltas rather than storing the full revision files is to save disk space.

The change control facilities provided by SCCS and RCS include the ability to incorporate restrictions on the set of individuals who can create new versions, and facilities for checking components in and out.

Individual developers check out components and modify them. After they have made all necessary changes to a module and after the changes have been reviewed, they check in the changed module into SCCS or RCS.

Revisions are denoted by numbers in ascending order, e.g., 1.1, 1.2, 1.3, etc. It is also possible to create variants or revisions of a component by creating a fork in the development history.

MISCELLANEOUS PLANS

Besides cost estimation, scheduling, and staffing plans, project managers plan several other things during the project planning stage.

An important task at this stage is the selection of a suitable development process model.

Different problems require either adopting an entirely different process model or suitably tailoring the standard process model adopted by a company.

For example, a routine development work may require a waterfall model to be followed, and an ambitious and technically challenging project may require an evolutionary or prototyping development model to be adopted.

Also, depending upon the type of the project, some life cycle phases may be omitted, modified, or new phases may be added to a selected life cycle model.

For example, for a software maintenance project, the design phase may be modified to a design modification stage.

Thus during the project planning stage, the project manager may have to select a suitable process model and do any required tailoring.