Software Configuration Management Vs Software Maintenance

<< Attributes of Software Design, Key Features of Design

Quality Assurance Management, Quality Factors >>

Software Project Management (CS615)

LECTURE # 17

2. Software Development Fundamentals

Technical Fundamentals

2.14 Software Configuration management

b. Controlling Versions

Version control combines procedures and tools to manage different versions

of configuration objects that are created during software product development.

To control versions, you can use Version Control Register. In Version Control

identification numbers, their versions, and dates of validity. It is advisable to

release a baseline after a version is released. Baseline is a specification or a

product that is formally reviewed and agreed upon. This serves as the basis for

further development. Baseline can be changed only through formal change

control procedures. A baseline consists of a set of SCIs that are logically

related to each other. Baselines are established when subsequent changes to

the SCIs need to be controlled. Version control is essential so that everybody

uses only the latest version. Any kind of version mismatch might result in

rework.

c. Controlling Changes

Uncontrolled change can lead to chaos. Change control combines human

procedures and automated tools to provide a mechanism for controlling

change. The purpose of change control is to monitor and control changes in

order to baseline SCIs. There are various reasons that trigger changes. A

problem report might call for a change. Similarly, suggestions or ideas from

brainstorming sessions and feedback from clients can result in change.

Modifications or addition to functionality and changes in environment can

also cause changes. The Figure 1 explains the formal change control process

using a flow chart.

112

Software Project Management (CS615)

Start

Change request is made

Change request is logged

Change request is evaluated

Outcome is notified

Yes

Is the

Request

Rejected?

Is the

Yes

Request

Deferred?

Change request is implemented

Stop

Figure 1: Formal Change Control Process

A request for change triggers that change control procedure. Then request is

logged in the change request register. Next, the change request number is

recorded in the change request evaluation plan. The request is evaluated and

analyzed to check if the change is valid. Change request is also evaluated in

113

Software Project Management (CS615)

terms of the number of items affected and the effort involved in effecting the

change. Finally, the possible outcome of the change request is communicated.

The request for change is rejected, deferred, or approved. If the request for

change is rejected, the requestor needs to log a fresh request. A deferred

change request is evaluated at a later date while the change request that is

approved is implemented.

There are tools that provide facilities to check in and check out so that the

same version of the object is not updated more than once. The check-in and

checkout facilities provide synchronization control. Synchronization control

helps to ensure that parallel changes performed by two different people do not

overwrite one another.

d. Auditing

Configuration audit is conducted formally by the SQA group in projects

where SCM is a formal activity. The identification, version control, and

change control tasks help the developer maintain order and decorum in an

environment of change. However, the control mechanisms track a change only

until an item is generated. FTRs and software configuration audits (SCA) are

conducted to ensure that change is properly implemented. FTR verifies the

technical correctness of the SCI that is subjected to change. SCA assesses

those characteristics of an SCI that are not considered during FTRs. Audit

verifies whether the changes specified in the request for change are made and

additional modifications, if any, are also noted. Audits ensure that FTRs are

conducted to check for technical correctness. Audits verify that changes made

are highlighted in the SCI. The change date and change author are specified

and the attributes of SCI reflect the change. The SCM procedures for noting,

recording, and reporting change are also followed. Audits also ensure that

related SCIs are updated.

e. Communicating Changes

Another task of SCM is communicating changes. This task ensures

communication between different members in the project. It notes the

activities performed, the time when they are performed, those involved in the

activities, and those affected by the activities. In short, the task is all about

status reporting. In a large project, there is a possibility of miscommunication

among various people involved in the project. This is usually done using

configuration status report shown in Table 11.7. The table contains the name

of the SCI, the latest released version, the date of release, brief description of

changes performed, and associated change request. Further details of the

changes can be obtained from the associated change request. There can be

instances where two developers may be trying to modify the same software

configurable item with different and conflicting intentions. Absence of status

reporting could result in incorrect decisions being taken or important decisions

114

Software Project Management (CS615)

not being communicated. At times, those who should be pointing out the

serious side effects caused by a change are not aware of the implementation of

the change. There are also instances of version mismatch when teams are

unaware of the latest version to be followed. To avoid such hazards due to

lack of communication among the project team, changes are communicated

among team members. Therefore, status reporting provides information about

each change to those who need to know. Software configuration management

takes care of changes in a software process. SCM identifies controls, audits,

and reports modifications that occur during software development. SCM helps

maintain the integrity of configurable items produced during software

development.

⇒ Software Configuration Management Vs Software Maintenance

SCM is an integral part of SQA. SCM involves assessing the impact of the

changes made during SQA activities and making decisions based on cost and

benefit analysis. SCM can be defined as the art of identifying, organizing, and

controlling changes in a software project with the objective of minimizing

mistakes. SCM is different from software maintenance. Software maintenance is

required after the software is delivered to the client and is put into operation. As

opposed to this, SCM is a set of tracking and controlling activities that begins

when a software project begins and ends only when the software is taken out of

operation.

⇒ Baselines vs. Interim Versions

SCM differentiates between baselines and interim versions. A baseline is a tested

and certified version of a system. Baselines can be assigned version numbers such

as 1.0, 2.0, 3.0, and so on. A baseline usually undergoes intensive testing. Interim

versions, on the other hand, have version numbers, such as 1.1 or 1.2. The interim

version is a temporary version. Interim versions have a short life and survive only

during bug fixing, testing, or debugging. However, interim versions also have a

unique version number or name. Baselines are more visible with the marketing

team and the vendors than the interim versions. However, as part of SCM, all

versions of changes are saved, clearly labeled, and archived. Archiving is the

process of maintaining controlled copies of prior versions. Archiving helps in re-

creating earlier versions in the event of data loss or data corruption.

⇒ Effective Configuration Control

Effective configuration control requires effective and well-defined organization.

Any configuration control method must be based on the following four concepts:

A clearly defined configuration management authority must be established.

Configuration control standards, procedures and guidelines must be produced and

distributed to the developers.

115

Software Project Management (CS615)

Configuration control cannot be effective without the necessary tools and

facilities.

A configuration management plan must be developed at the beginning of the

project.

The configuration management environment consists of the resources necessary

for the implementation of the configuration control plan.

Configuration control tools, including:

Automatic version control and

Change control tools

Monitoring, auditing and registration support utilities

Storage facilities; a safe repository for all approved configuration items,

including:

On-site storage for the day to day development process

Off-site storage for catastrophe recovery

⇒ Guidelines for effective configuration management

The following are some additional guidelines for effective configuration

management. Some of these guidelines are equally applicable to other

management support functions.

Configuration management requires authority in order to be effective. This

authority must be clearly delegated by the project manager to the responsible

engineers. Any configuration management plan will become meaningless if

the plan cannot be enforced.

Blunt enforcement of any plan policy or standard is best avoided, whenever

possible. One of the qualities of a good manager is the ability to apply policy

with minimal enforcement. Whenever policies and standards are readily

accepted by the developers, they are more willingly followed and there are

fewer rejections of submitted material. This leads to a more efficient

development process.

Configuration management should be implemented from the start of a

software project. Many of the formal documents issued during the initial

concept phase are crucial for the requirements and design phases, and must be

placed under configuration control.

The early application of configuration management is especially important in

rapid prototyping, spiral models, or other iterative development

methodologies. These development approaches initially produce several

116

Software Project Management (CS615)

versions of each product. Many different versions can become an engineering

nightmare without orderly configuration control.

Occasionally some software configuration control activities may overlap with

software quality assurance activities. In small projects, these two functions

may be assigned to a single support engineer. Even in large projects, these two

functions are sometimes performed by a single support group.

⇒ Misapplication of Guidelines

It should be noted that configuration management can be greatly exaggerated.

The various configuration control activities are not an objective in themselves,

they are a means.

A typical example of the misapplication of configuration management (and

misguided quality control), is a requirement to modify reused software to

comply with current standards and procedures.

Reused software is software developed previously in another project, and

found suitable to be incorporated into the current project. In such cases it

rarely makes sense to modify a complete and working product in order to

make it comply with administrative standards intended to make it a complete

and working product.

117

Table of Contents: