Throughout development, software consists of a collection of items (such as programs, data and documents) that can easily be changed. During software development, the design, code, and even requirements are often changed, and the changes occur at any time during the development. This easily changeable nature of software and the fact that changes often take place require that changes be done in a controlled manner.
Software configuration management (SCM) is the discipline for systematically controlling the changes that take place during development. Software configuration management is a process independent of the development process largely because most development models cannot accommodate change at any time during development. SCM can be considered as having three major components:
Software configuration identification
Change control
Status accounting and auditing
We’ll be covering the following topics in this tutorial:
Configuration identification:
The first requirement for any change management is to have clearly agreed-on basis for change. That is, when a change is done, it should be clear to what changes has been applied. This requires baselines to be established. A baseline change is the changing of the established baseline, which is controlled by SCM.
After baseline changes the state of the software is defined by the most recent baseline and the changes that were made. Some of the common baselines are functional or requirements baseline, design baseline, and product or system baseline. Functional or requirement baseline is generally the requirements document that specifies the functional requirements for the software. Design baseline consists of the different components in the software and their designs. Product or system baseline represents the developed system.
It should be clear that a baseline is established only after the product is relatively stable. Though the goal of SCM is to control the establishment and changes to these baselines, treating each baseline as a single unit for the purpose of change is undesirable, as the change may be limited to a very small portion of the baseline.
Change control:
Most of the decisions regarding the change are generally taken by the configuration control board (CCB), which is a group of people responsible for configuration management, headed by the configuration manager. For smaller projects, the CCB might consist of just one person. A change is initiated by a change request.
The reason for change can be anything. However, the most common reasons are requirement changes, changes due to bugs, platform changes, and enhancement changes. The CR for change generally consists of three parts. The first part describes the change, reason for change, the SCIs that are affected, the priority of the change, etc.
The second part, filled by the CM, describes the decision taken by the CCB on this CR, the action the CM feels need to be done to implement this change and any other comments the CM may have. The third part is filled by the implementer, which later implements the change.
Status accounting and auditing:
For status accounting, the main source of information is the CRs and FRs themselves. Generally, a field in the CR/FR is added that specifies its current status. The status could be active, complete, or not scheduled. Information about dates and efforts can also be added to the CR, the information from the CRs/FRs can be used to prepare a summary, which can be used by the project manager and the CCB to track all the changes.
Dinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular