SCM

SCM

Software systems are constantly undergoing change during development and maintenance. By software systems we include all software artifacts such as requirements and design documents, test plans, user manuals, code, and test cases. Different versions, variations, builds, and releases exist for these artifacts. Organizations need staff, tools, and techniques to help them track and manage these artifacts and changes to the artifacts that occur during development and maintenance. The Capability Maturity Model includes configuration management as a Key Process Area at level 2. This is an indication of its fundamental role in support of repeatable, controlled, and managed processes. To control and monitor the testing process, testers and test mangers also need access to configuration management tools and staff.

There are four major activities associated with configuration management. These are:

1 . Identification of the Configuration Items

The items that will be under configuration control must be selected, and the relationships between them must be formalized. An example relationship is ―part-of‖ which is relevant to composite items. Relationships are often expressed in a module interconnection language (MIL). Figure 9.7 shows four configuration items, a design specification, a test specification, an object code module, and source code module as they could exist in a configuration management system (CMS) repository (see item 2 below for a brief description of a CMS). The arrows indicate links or relationships between them. Note in this example that the configuration management system is aware that these four items are related only to one another and not to other versions of these items in the repository.

In addition to identification of configuration items, procedures for establishment of baseline versions for each item must be in place.

Baselines are formally reviewed and agreed upon versions of software artifacts, from which all changes are measured. They serve as the basis for further development and can be changed only through formal change procedures. Baselines plus approved changes from those baselines constitute the correct configuration identification for the item. [11].

2 . Change Control

There are two aspects of change control—one is tool-based, the other team-based. The team involved is called a configuration control board. This group oversees changes in the software system. The members of the board should be selected from SQA staff, test specialists, developers, and analysts. It is this team that oversees, gives approval for, and follows up on changes. They develop change procedures and the formats for change request forms. To make a change, a change request form must be prepared by the requester and submitted to the board. It then reviews and approves/ disapproves. Only approved changes can take place. The board also participates in configuration reporting and audits as described further on in this section.

In addition to the configuration control board, control of configuration items requires a  configuration management system (CMS) that will store the configuration items in a repository (or project database) and maintain control and access to those items. The CMS will manage the versions and variations of the items. It will keep track of the items and their relationships with one another. For example, developers and testers need to know which set of test cases is associated with which design item, and which version of object code is associated with which version of source code? The CMS will provide the information needed to answer these questions by supporting relationships as shown in Figure 9.7. It also supports baseline versions for each configuration item, and it only allows designated engineers to make changes to a configuration item after formal approval by the change control board. The software engineer must check- out the item undergoing change from the CMS. A copy of it is made in her work station. When the changes are complete, and they are reviewed, the new version is ―checked in‖ to the CMS, and the version control mechanism in the CMS creates the newest version in its repository. Relationships to existing configuration items are updated. TheCMScontrols change-making by ensuring that an engineer has the proper access rights to the configuration item. It also synchronizes the change-making process so that parallel changes made by different software engineers do not overwrite each other. The CMS also allows software engineers to create builds of the system consisting of different versions and variations of object and source code.

3. Configuration status reporting

These reports help to monitor changes made to configuration items. They contain a history of all the changes and change information for each configuration item. Each time an approved change is made to a configuration item, a configuration status report entry is made. These reports are kept in the CMS database and can be accessed by project personnel so that all can be aware of changes that are made. The reports can answer questions such as:

• who made the change;

• what was the reason for the change;

• what is the date of the change;

• what is affected by the change.

Reports for configuration items can be disturbed to project members and discussed at status meetings.

4. Configuration audits

After changes are made to a configuration item, how do software engineers follow up to ensure the changes have been done properly? One way to do this through a technical review, another through a configuration audit. The audit is usually conducted by the SQA group or members of the configuration control board. They focuses on issues that are not covered in a technical review. A checklist of items to cover can serve as the agenda for the audit. For each configuration item the audit should cover the following:

(i) Compliance with software engineering standards. For example, for the source code modules, have  the standards for indentation, white space, and comments been followed?

(ii) Theconfigurationchange procedure. Has it been followed correctly?

(iii) Related configuration items. Have they been updated?

(iv) Reviews. Has the configuration item been reviewed?

Why is configuration management of interest to testers? Configuration management will ensure that test plans and other test-related documents are being prepared, updated, and maintained properly. To support these objectives, Ayer has suggested a test documentation checklist to be used for configuration audits to verify the accuracy and completeness of test documentation [12]. Configuration management also allows the tester to determine if the proper tests are associated with the proper source code, requirements, and design document versions, and that the correct version of the item is being tested. It also tells testers who is responsible for a given item, if any changes have been made to it, and if it has been reviewed before it is scheduled for test.