5.4 Configuration Management(K2)



Our systems are made up of a number of items (or things) components, documents, programs, etc. Configuration Management is all about effective and efficient management and control of these items.

During the lifetime of the system many of the items will change. They will change for a number of reasons like :
· new features, defect fixes, environment changes, etc.
· We might also have different items for different customers, such as version A contains modules 1,2,3,4 & 5 and version B contains modules 1,2,3,6 & 7. We may need different modules depending on the environments they run under (such as Windows NT and Windows 2000).

An indication of a good Configuration Management system is to ask ourselves whether we can go back two releases of our software and perform some specific tests with relative ease.

A good definition of configuration management is given in the ANSI/IEEE Standard 729-1983, Software Engineering Terminology. This says that configuration management is:
  “the process of identifying and defining Configuration Items in a system,
  controlling the release and change of these items throughout the system life cycle,
  recording and reporting the status of configuration items and change requests, and
  verifying the completeness and correctness of configuration items.”

This definition neatly breaks down configuration management into four key areas:
§ configuration identification;
§ configuration control;
§ configuration status accounting; and
§ configuration audit.

Configuration identification is the process of identifying and defining Configuration Items in a system. Configuration Items are those items that have their own version number such that when an item is changed, a new version is created with a different version number. So configuration identification is about identifying what are to be the configuration items in a system, how these will be structured (where they will be stored in relation to each other) the version numbering system, selection criteria, naming conventions, and baselines. A baseline is a set of different configuration items (one version of each) that has a version number itself. Thus, if program X comprises modules A and B, we could define a baseline for version 1.1 of program X that comprises version 1.1 of module A and version 1.1 of module B. If module B changes, a
new version (say 1.2) of module B is created. We may then have a new version of program X, say baseline 2.0 that comprises version 1.1 of module A and version 1.2 of module B.

Configuration control is about the provision and management of a controlled library containing all the configuration items. This will govern how new and updated configuration items can be submitted into and copied out of the library. Configuration control also determines how defect reporting and change control is handled (since defect fixes usually involve new versions of configuration items being created).

Status accounting enables traceability and impact analysis. A database holds all the information relating to the current and past states of all configuration items. For example, this would be able to tell us which configuration items are being updated, who has them and for what purpose.

Configuration auditing is the process of ensuring that all configuration management procedures have been followed and of verifying the current state of any and all configuration items is as it is supposed to be. We should be able to ensure that a delivered system is a complete system (i.e. all necessary configuration items have been included and extraneous items have not been included).

The purpose of configuration management is to establish and maintain the integrity of the products (components, data and documentation) of the software or system through the project and product life cycle.
For testing, configuration management may involve ensuring that:
§ All items of testware are identified, version controlled, tracked for changes, related to each other and related to development items (test objects) so that traceability can be maintained throughout the test process.
§ All identified documents and software items are referenced unambiguously in test documentation.

Often organisations do not appreciate the need for good configuration management until they experience one or more of the problems that can occur without it. Some problems that commonly occur as a result of poor configuration management systems include:

§ the inability to reproduce a defect reported by a customer;
§ two programmers have the same module out for update and one overwrites the other’s change;
§ unable to match object code with source code;
§ do not know which fixes belong to which versions of the software;
§ defects that have been fixed reappear in a later release;
§ a defect fix to an old version needs testing urgently, but tests have been updated.
 

Configuration Management in Testing
For the tester, configuration management helps to uniquely identify (and to reproduce) the tested item, test documents, the tests and the test harness.

During test planning, the configuration management procedures and infrastructure (tools) should be chosen, documented and implemented.
§ Configuration Items of testing include :
Test plans
Test specifications
Test data and test harness
Test results

§ Configuration management in testing is maintaining integrity and traceability of the test ware.

§ Configuration management of the system to be tested is the responsibility of the system development team.

§ The system release documentation includes the details on the version number of release and changes made to the release when the system is released for testing.

0 comments:

Post a Comment